6:09 a.m.
Hi,
With the upcoming windows support and simple push change (making simple push more like
'normal') the number of ‘special’ keys in our message is increasing. Right now we
are mixing our ‘special’ keys with those the user can add, but we keep simple push out of
it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the simple-push into
the message as well. As for the windows support there are a lot more types of messages you
can send. The most normal form is called ‘toast’, but there are other ones for when you
app is pinned to the home screen. Then one can send message that contain pictures. To
support all of this we need something like this:
https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict with the users
own data, so I propose we put the user data into a separate data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"simple-push": "version=123",
"data" : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}
}
WDYT?
Cheers,
Erik Jan
6:30 a.m.
+1 on a custom-data section.
Going even further as we add more platforms support, I think having sth like cordova push
config:
http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sa...
where you have platform specific section would be nice.
++
Corinne
On 21 Aug 2014, at 13:09, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
With the upcoming windows support and simple push change (making simple push more like
'normal') the number of ‘special’ keys in our message is increasing. Right now we
are mixing our ‘special’ keys with those the user can add, but we keep simple push out of
it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org",
....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the simple-push into
the message as well. As for the windows support there are a lot more types of messages you
can send. The most normal form is called ‘toast’, but there are other ones for when you
app is pinned to the home screen. Then one can send message that contain pictures. To
support all of this we need something like this:
https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict with the users
own data, so I propose we put the user data into a separate data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com", "someone(a)aerogear.org",
....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"simple-push": "version=123",
"data" : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}
}
WDYT?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
6:35 a.m.
On Thu, Aug 21, 2014 at 1:30 PM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
+1 on a custom-data section.
Going even further as we add more platforms support, I think having sth
like cordova push config:
http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sa...
where you have platform specific section would be nice.
perhaps, not fully convinced atm. Original idea was to have a simple format
for multiple platforms.
++
Corinne
On 21 Aug 2014, at 13:09, Erik Jan de Wit <edewit(a)redhat.com> wrote:
> Hi,
>
> With the upcoming windows support and simple push change (making simple
push more like 'normal') the number of ‘special’ keys in our message is
increasing. Right now we are mixing our ‘special’ keys with those the user
can add, but we keep simple push out of it:
>
> {
>
>
> "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
>
>
> "alias" : ["user(a)account.com", "someone(a)aerogear.org",
....],
>
>
> "categories" : ["someCategory", "otherCategory"],
>
>
> "deviceType" : ["iPad", "AndroidTablet"],
>
>
> "ttl" : 3600,
>
>
> "message": {
>
>
> "alert":"HELLO!",
>
>
> "sound":"default",
>
>
> "badge":7,
>
>
> "content-available" : true,
>
>
> "action-category" : "some_category",
>
>
>
> "someKey":"some value",
>
>
> "anotherCustomKey":"some other value"
>
>
> },
> "simple-push": "version=123”
> }
>
>
> As simple push is going to be more like ‘normal’ push why not move the
simple-push into the message as well. As for the windows support there are
a lot more types of messages you can send. The most normal form is called
‘toast’, but there are other ones for when you app is pinned to the home
screen. Then one can send message that contain pictures. To support all of
this we need something like this:
https://gist.github.com/edewit/305d76c31960aa6254a9
>
> Adding all these ‘special’ keys will make it easier to get into a
conflict with the users own data, so I propose we put the user data into a
separate data object, like so:
>
> {
>
>
> "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
>
>
> "alias" : ["user(a)account.com", "someone(a)aerogear.org",
....],
>
>
> "categories" : ["someCategory", "otherCategory"],
>
>
> "deviceType" : ["iPad", "AndroidTablet"],
>
>
> "ttl" : 3600,
>
>
> "message": {
>
>
> "alert":"HELLO!",
>
>
> "sound":"default",
>
>
> "badge":7,
>
>
> "content-available" : true,
>
>
> "action-category" : "some_category",
> "simple-push": "version=123",
>
>
> "data" : {
>
>
> "someKey":"some value",
>
>
> "anotherCustomKey":"some other value"
>
>
> }
>
>
> }
> }
>
>
> WDYT?
>
> Cheers,
> Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:34 a.m.
Hi Erik,
overall I am not against changes for 1.1.x, on our master branch. Here is
something that Sebi mentioned a few month ago:
https://issues.jboss.org/browse/AGPUSH-534
With some API change, coming up, let's not forget about "REST API
Versioning", he discussed at our Face2Face meeting:
http://oksoclap.com/p/jbrS1EHWkI
(looks like in that session the majority preferred headers over URI).
We have to support the 1.0.0 APIs for quite a while.
-Matthias
On Thu, Aug 21, 2014 at 1:09 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi,
With the upcoming windows support and simple push change (making simple
push more like 'normal') the number of ‘special’ keys in our message is
increasing. Right now we are mixing our ‘special’ keys with those the user
can add, but we keep simple push out of it:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",
"someKey":"some value",
"anotherCustomKey":"some other value"
},
"simple-push": "version=123”
}
As simple push is going to be more like ‘normal’ push why not move the
simple-push into the message as well. As for the windows support there are
a lot more types of messages you can send. The most normal form is called
‘toast’, but there are other ones for when you app is pinned to the home
screen. Then one can send message that contain pictures. To support all of
this we need something like this:
https://gist.github.com/edewit/305d76c31960aa6254a9
Adding all these ‘special’ keys will make it easier to get into a conflict
with the users own data, so I propose we put the user data into a separate
data object, like so:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",*
"simple-push": "version=123",*
*"data"* : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}}
WDYT?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:46 a.m.
overall I am not against changes for 1.1.x, on our master branch. Here is something that
Sebi mentioned a few month ago: https://issues.jboss.org/browse/AGPUSH-534
right I like this as well, but here the users data is also mixed with the message, that
was the point.
With some API change, coming up, let's not forget about "REST API
Versioning", he discussed at our Face2Face meeting: http://oksoclap.com/p/jbrS1EHWkI
(looks like in that session the majority preferred headers over URI).
We have to support the 1.0.0 APIs for quite a while.
Sure, but because we have a version can’t mean that we cannot change things I hope. We
just need to have a good mechanism inlace to maintain these versions.
6:51 a.m.
On Thu, Aug 21, 2014 at 1:46 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
overall I am not against changes for 1.1.x, on our master branch. Here is
something that Sebi mentioned a few month ago:
https://issues.jboss.org/browse/AGPUSH-534
right I like this as well, but here the users data is also mixed with the
message, that was the point.
With some API change, coming up, let's not forget about "REST API
Versioning", he discussed at our Face2Face meeting:
http://oksoclap.com/p/jbrS1EHWkI
(looks like in that session the majority preferred headers over URI).
We have to support the 1.0.0 APIs for quite a while.
Sure, but because we have a version can’t mean that we cannot change
things I hope.
nah, not at all :-) That's why we discussed 'REST API Versioning' at the
meeting
We just need to have a good mechanism inlace to maintain these
versions.
yep, I'd say once that is in place, we can look at changing APIs
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:07 a.m.
found it :-)
On Thu, Aug 21, 2014 at 1:09 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
{
"variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
"alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
"categories" : ["someCategory", "otherCategory"],
"deviceType" : ["iPad", "AndroidTablet"],
"ttl" : 3600,
"message": {
"alert":"HELLO!",
"sound":"default",
"badge":7,
"content-available" : true,
"action-category" : "some_category",*
"simple-push": "version=123",*
*"data"* : {
"someKey":"some value",
"anotherCustomKey":"some other value"
}
}}
I think I do like 'data' better than 'payload' (from the PR)
-M
WDYT?
Cheers,
Erik Jan
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3:59 a.m.
On Thu, Oct 23, 2014 at 6:07 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
found it :-)
On Thu, Aug 21, 2014 at 1:09 PM, Erik Jan de Wit <edewit(a)redhat.com>
wrote:
> {
> "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e",
"444939cd-ae63-4ce1-96a4-de74b77e3737" ....],
> "alias" : ["user(a)account.com",
"someone(a)aerogear.org", ....],
> "categories" : ["someCategory",
"otherCategory"],
> "deviceType" : ["iPad", "AndroidTablet"],
> "ttl" : 3600,
> "message": {
> "alert":"HELLO!",
> "sound":"default",
> "badge":7,
> "content-available" : true,
> "action-category" : "some_category",*
"simple-push": "version=123",*
> *"data"* : {
> "someKey":"some value",
> "anotherCustomKey":"some other value"
> }
> }}
>
>
I think I do like 'data' better than 'payload' (from the PR)
Sounds good to me or 'custom-data'
-M
>
>
> WDYT?
>
> Cheers,
> Erik Jan
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
9:15 a.m.
'payload' is the term used for this kind of "in-message custom data"
since the early years of EIP tools (before camel was born)
Any strong reason to avoid it?
Also, as others pointed out, we have json keys with dashes, is this
really desired? because consistency :)
--
qmx
9:19 a.m.
On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me> wrote:
'payload' is the term used for this kind of "in-message
custom data"
since the early years of EIP tools (before camel was born)
nested payload, inside of message, I am not sure
Any strong reason to avoid it?
Also, as others pointed out, we have json keys with dashes, is this
really desired? because consistency :)
yeah, we have a few, to stay in sync a/ le apple (action-category and
content-available)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
9:30 a.m.
On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
'payload' is the term used for this kind of "in-message custom data"
since the early years of EIP tools (before camel was born)
nested payload, inside of message, I am not sure
Thinking a bit more about it, I don’t like data (it’s to generic everything is data) and I
don’t like payload either (because everything is message payload) can’t we use something
like ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a little bit
more to what this is.
Any strong reason to avoid it?
yeah, let’s keep the once that are there because the are consistent with apple
9:54 a.m.
On Mon, Oct 27, 2014 at 3:30 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
> 'payload' is the term used for this kind of "in-message custom
data"
> since the early years of EIP tools (before camel was born)
>
nested payload, inside of message, I am not sure
Thinking a bit more about it, I don’t like data (it’s to generic
everything is data) and I don’t like payload either (because everything is
message payload)
I hear you! data is pretty generic
can’t we use something like ‘customData’ , ‘userData’, `userKeys` or
perhaps something that says a little bit more to what this is.
Good suggestions, I do like user-data!
:)
>
> Any strong reason to avoid it?
>
yeah, let’s keep the once that are there because the are consistent with
apple
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
11:50 a.m.
On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
> On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos
<qmx(a)qmx.me> wrote:
> 'payload' is the term used for this kind of "in-message custom
data"
> since the early years of EIP tools (before camel was born)
>
> nested payload, inside of message, I am not sure
>
Thinking a bit more about it, I don’t like data (it’s to generic
everything is data) and I don’t like payload either (because
everything is message payload) can’t we use something like
‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
little bit more to what this is.
+1 to userData, clearly communicates intent (if
y'all dislike payload) :D
--
qmx
1:36 p.m.
On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
> > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> > 'payload' is the term used for this kind of "in-message custom
data"
> > since the early years of EIP tools (before camel was born)
> >
> > nested payload, inside of message, I am not sure
> >
>
> Thinking a bit more about it, I don’t like data (it’s to generic
> everything is data) and I don’t like payload either (because
> everything is message payload) can’t we use something like
> ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
> little bit more to what this is.
+1 to userData, clearly communicates intent (if y'all dislike payload) :D
how about user-data ?
(due to consistency ?) :)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
7:30 p.m.
-1 to payload, +1 to user-data || userData
-- Passos
On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
> > > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> > > 'payload' is the term used for this kind of "in-message custom
data"
> > > since the early years of EIP tools (before camel was born)
> > >
> > > nested payload, inside of message, I am not sure
> > >
> >
> > Thinking a bit more about it, I don’t like data (it’s to generic
> > everything is data) and I don’t like payload either (because
> > everything is message payload) can’t we use something like
> > ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
> > little bit more to what this is.
> +1 to userData, clearly communicates intent (if y'all dislike payload) :D
>
how about user-data ?
(due to consistency ?) :)
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:11 a.m.
+1 for user-data
-
Christos
On Oct 28, 2014, at 2:30 AM, Daniel Passos <daniel(a)passos.me> wrote:
-1 to payload, +1 to user-data || userData
-- Passos
On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
> > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me> wrote:
> > 'payload' is the term used for this kind of "in-message custom
data"
> > since the early years of EIP tools (before camel was born)
> >
> > nested payload, inside of message, I am not sure
> >
>
> Thinking a bit more about it, I don’t like data (it’s to generic
> everything is data) and I don’t like payload either (because
> everything is message payload) can’t we use something like
> ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
> little bit more to what this is.
+1 to userData, clearly communicates intent (if y'all dislike payload) :D
how about user-data ?
(due to consistency ?) :)
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
2:17 a.m.
+1 for user-data
On 28 October 2014 08:11, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
+1 for user-data
-
Christos
On Oct 28, 2014, at 2:30 AM, Daniel Passos <daniel(a)passos.me> wrote:
-1 to payload, +1 to user-data || userData
-- Passos
On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>
>
> On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>
>> On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
>> > > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
>> > > 'payload' is the term used for this kind of "in-message
custom data"
>> > > since the early years of EIP tools (before camel was born)
>> > >
>> > > nested payload, inside of message, I am not sure
>> > >
>> >
>> > Thinking a bit more about it, I don’t like data (it’s to generic
>> > everything is data) and I don’t like payload either (because
>> > everything is message payload) can’t we use something like
>> > ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
>> > little bit more to what this is.
>> +1 to userData, clearly communicates intent (if y'all dislike payload) :D
>>
>
> how about user-data ?
> (due to consistency ?) :)
>
>
>
>
>>
>> --
>> qmx
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:15 a.m.
Okay "user-data" seems to be the winner ;)
Let's go for that !
NB : For the JavaSender, it will be camelCased message.userData(...)
On Tue, Oct 28, 2014 at 8:17 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com>
wrote:
+1 for user-data
On 28 October 2014 08:11, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
> +1 for user-data
>
> -
> Christos
>
>
> On Oct 28, 2014, at 2:30 AM, Daniel Passos <daniel(a)passos.me> wrote:
>
> -1 to payload, +1 to user-data || userData
>
> -- Passos
>
> On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>>
>>
>> On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>
>>> On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
>>> > > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me>
wrote:
>>> > > 'payload' is the term used for this kind of
"in-message custom data"
>>> > > since the early years of EIP tools (before camel was born)
>>> > >
>>> > > nested payload, inside of message, I am not sure
>>> > >
>>> >
>>> > Thinking a bit more about it, I don’t like data (it’s to generic
>>> > everything is data) and I don’t like payload either (because
>>> > everything is message payload) can’t we use something like
>>> > ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
>>> > little bit more to what this is.
>>> +1 to userData, clearly communicates intent (if y'all dislike payload)
>>> :D
>>>
>>
>> how about user-data ?
>> (due to consistency ?) :)
>>
>>
>>
>>
>>>
>>> --
>>> qmx
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:21 a.m.
On Tue, Oct 28, 2014 at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
Okay "user-data" seems to be the winner ;)
Let's go for that !
NB : For the JavaSender, it will be camelCased message.userData(...)
+1
On Tue, Oct 28, 2014 at 8:17 AM, Daniel Bevenius <
daniel.bevenius(a)gmail.com> wrote:
> +1 for user-data
>
> On 28 October 2014 08:11, Christos Vasilakis <cvasilak(a)gmail.com> wrote:
>
>> +1 for user-data
>>
>> -
>> Christos
>>
>>
>> On Oct 28, 2014, at 2:30 AM, Daniel Passos <daniel(a)passos.me> wrote:
>>
>> -1 to payload, +1 to user-data || userData
>>
>> -- Passos
>>
>> On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>>
>>>
>>> On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me> wrote:
>>>
>>>> On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
>>>> > > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos
<qmx(a)qmx.me>
>>>> wrote:
>>>> > > 'payload' is the term used for this kind of
"in-message custom
>>>> data"
>>>> > > since the early years of EIP tools (before camel was born)
>>>> > >
>>>> > > nested payload, inside of message, I am not sure
>>>> > >
>>>> >
>>>> > Thinking a bit more about it, I don’t like data (it’s to generic
>>>> > everything is data) and I don’t like payload either (because
>>>> > everything is message payload) can’t we use something like
>>>> > ‘customData’ , ‘userData’, `userKeys` or perhaps something that
says
>>>> a
>>>> > little bit more to what this is.
>>>> +1 to userData, clearly communicates intent (if y'all dislike
payload)
>>>> :D
>>>>
>>>
>>> how about user-data ?
>>> (due to consistency ?) :)
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> qmx
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:33 a.m.
On Oct 28, 2014, at 9:21 AM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
On Tue, Oct 28, 2014 at 2:15 PM, Sebastien Blanc <scm.blanc(a)gmail.com
<mailto:scm.blanc@gmail.com>> wrote:
Okay "user-data" seems to be the winner ;)
Let's go for that !
NB : For the JavaSender, it will be camelCased message.userData(...)
+1
should be no change other than docs for the node sender then
On Tue, Oct 28, 2014 at 8:17 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com
<mailto:daniel.bevenius@gmail.com>> wrote:
+1 for user-data
On 28 October 2014 08:11, Christos Vasilakis <cvasilak(a)gmail.com
<mailto:cvasilak@gmail.com>> wrote:
+1 for user-data
-
Christos
On Oct 28, 2014, at 2:30 AM, Daniel Passos <daniel(a)passos.me
<mailto:daniel@passos.me>> wrote:
> -1 to payload, +1 to user-data || userData
>
> -- Passos
>
> On Mon, Oct 27, 2014 at 4:36 PM, Matthias Wessendorf <matzew(a)apache.org
<mailto:matzew@apache.org>> wrote:
>
>
> On Mon, Oct 27, 2014 at 5:50 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
> On Mon, Oct 27, 2014 at 03:30:51PM +0100, Erik Jan de Wit wrote:
> > > On Mon, Oct 27, 2014 at 3:15 PM, Douglas Campos <qmx(a)qmx.me
<mailto:qmx@qmx.me>> wrote:
> > > 'payload' is the term used for this kind of "in-message custom
data"
> > > since the early years of EIP tools (before camel was born)
> > >
> > > nested payload, inside of message, I am not sure
> > >
> >
> > Thinking a bit more about it, I don’t like data (it’s to generic
> > everything is data) and I don’t like payload either (because
> > everything is message payload) can’t we use something like
> > ‘customData’ , ‘userData’, `userKeys` or perhaps something that says a
> > little bit more to what this is.
> +1 to userData, clearly communicates intent (if y'all dislike payload) :D
>
> how about user-data ?
> (due to consistency ?) :)
>
>
>
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
<http://matthiaswessendorf.wordpress.com/>
> sessions: http://www.slideshare.net/mwessendorf
<http://www.slideshare.net/mwessendorf>
> twitter: http://twitter.com/mwessendorf <http://twitter.com/mwessendorf>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
<http://matthiaswessendorf.wordpress.com/>
sessions: http://www.slideshare.net/mwessendorf
<http://www.slideshare.net/mwessendorf>
twitter: http://twitter.com/mwessendorf
<http://twitter.com/mwessendorf>_______________________________________...
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>
3710
days inactive
3778
days old
19 comments
9 participants
participants (9)
-
Christos Vasilakis -
Corinne Krych -
Daniel Bevenius -
Daniel Passos -
Douglas Campos -
Erik Jan de Wit -
Lucas Holmquist -
Matthias Wessendorf -
Sebastien Blanc