Hey guys, I've been thinking and got an idea that would improve consistency of the push messaging. Right now, Android and iOS are kind of consistent, so when you send a push message, they both receive the same data. But simplepush behaves differently. I know, it's because mozilla made it that way, but let me show you my idea. Let's say we have this payload, that's gonna be send to all three platforms at the same time: { "postId" : "1234567890", "title" : "Aerogear RULEZ!" "simplepush" : "version=123" } This payload has 88 bytes, so even for APNS, the size of this message is not a problem (GCM even has limit of 4kB). And I've counted the simplepush field into that size (that would of course get removed from the final message). As you can see, there is no change in the message format. There are several ways for declaring which messages should be saved and which not. It might be "variant-scoped" or "category-scoped" (making it category-scoped would mean there would have to be some category management). So let's say that we have it variant-scoped, meaning that when you create a Simplepush variant, you can decide if messages should be stored or not. If you want them stored, the unifiedpush server will store the payload under the version number (it will store only the latest payload for the version number) and the aerogear-js will then fetch the payload automatically and give it to your callback. That way, you wouldn't have to make your own web service and logic to pull the data. In this example, we're talking about application that's made for browsing content of a website like the Verge, Engadget etc. The notification is then for notifying the user that a new post has been released. You could of course just send information that there is a new post and make the application pull it from the web. But that consumes additional battery and data for no reason. With this data, the post id and the title, you have enough to notify the user about new content and to be able to directly open your application and load desired post when the user wants to. And I'm not making this up, this is a real use case. We've made an application [1], that does exactly this, but uses just the GCM. Now if I wanted to make it use aerogear unified push, it'll be easy transition. If we had an iOS application, it would behave the same (or just very, very similar). But if we've built Firefox OS application using the simplepush notifications, we'd have to make additional logic just to fetch the post id and title. And that makes the simplepush inconsistent with the Android and iOS messaging. So to wrap it up, * you register simplepush variant, setting "storePayloads" to true * then you register a simplepush device for that variant, also with setting "fetchPayloads" to true * you send your message as usual ** you'll receive the payload directly on iOS and Android ** in JS, aerogear-js will first make a request to unifiedpush server, to fetch the payload, which will then deliver into your callback Let me be clear, that if you don't use the "storePayloads" and "fetchPayloads" (naming is temporary ofc), the simplepush would behave like it does now. If you'd use "storePayloads" but not "fetchPayloads", it would also behave like it does now, but the unifiedpush will store the payloads. Using "fetchPayloads" but not "storePayloads" would result into error on the JS client side. So, what do you think? Also, if something is not clear, just ask. PS: Some of you might say that push notifications are not meant to carry data. Well, the world is not always following the guidelines (also the GCM is made [2] to deliver data and APNS is somehow in between as it allows some data to be sent but not as much as GCM). 1 - https://play.google.com/store/apps/details?id=com.brainwashstudio.dotekom... 2 - http://developer.android.com/google/gcm/adv.html#payload _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi, Beside the legal considerations and the potentially security holes that could bring storing data on the UPS, I'm don't think it's the role of the Push server to store business specific logic.

It's more complex than just storing under the version, you got channels / categories / etc ... How do we manage this data ? How and when do we clean it up ? What about scalability if 5000000 users wants to check their Bacon Crush Game update at the same time, while UPS is pushing 2000000 messages to Happy Pig Game ? I know at a first glance it can be a bit frustrating when discovering the "spirit" of SimplePush but it is simple as the name said. What we could consider is some kind of external JS utility library where we could define "bridges" between SPS notifications and services (an AG Pipe for instance) : When a SPS message arrives for channel A , we call the Pipe associated to A.

Seb On Fri, Sep 13, 2013 at 1:54 PM, Tadeas Kriz <tkriz(a)redhat.com&gt; wrote: > Hey guys, > > I've been thinking and got an idea that would improve consistency of the > push messaging. Right now, Android and iOS are kind of consistent, so when > you send a push message, they both receive the same data. But simplepush > behaves differently. I know, it's because mozilla made it that way, but let > me show you my idea. > > Let's say we have this payload, that's gonna be send to all three > platforms at the same time: > > { > "postId" : "1234567890", > "title" : "Aerogear RULEZ!" > "simplepush" : "version=123" > } > This payload has 88 bytes, so even for APNS, the size of this message is > not a problem (GCM even has limit of 4kB). And I've counted the simplepush > field into that size (that would of course get removed from the final > message). > > As you can see, there is no change in the message format. There are > several ways for declaring which messages should be saved and which not. It > might be "variant-scoped" or "category-scoped" (making it category-scoped > would mean there would have to be some category management). So let's say > that we have it variant-scoped, meaning that when you create a Simplepush > variant, you can decide if messages should be stored or not. If you want > them stored, the unifiedpush server will store the payload under the > version number (it will store only the latest payload for the version > number) and the aerogear-js will then fetch the payload automatically and > give it to your callback. That way, you wouldn't have to make your own web > service and logic to pull the data. > > In this example, we're talking about application that's made for browsing > content of a website like the Verge, Engadget etc. The notification is then > for notifying the user that a new post has been released. You could of > course just send information that there is a new post and make the > application pull it from the web. But that consumes additional battery and > data for no reason. With this data, the post id and the title, you have > enough to notify the user about new content and to be able to directly open > your application and load desired post when the user wants to. > > And I'm not making this up, this is a real use case. We've made an > application [1], that does exactly this, but uses just the GCM. Now if I > wanted to make it use aerogear unified push, it'll be easy transition. If > we had an iOS application, it would behave the same (or just very, very > similar). But if we've built Firefox OS application using the simplepush > notifications, we'd have to make additional logic just to fetch the post id > and title. And that makes the simplepush inconsistent with the Android and > iOS messaging. > > So to wrap it up, > * you register simplepush variant, setting "storePayloads" to true > * then you register a simplepush device for that variant, also with > setting "fetchPayloads" to true > * you send your message as usual > ** you'll receive the payload directly on iOS and Android > ** in JS, aerogear-js will first make a request to unifiedpush server, to > fetch the payload, which will then deliver into your callback > > Let me be clear, that if you don't use the "storePayloads" and > "fetchPayloads" (naming is temporary ofc), the simplepush would behave like > it does now. If you'd use "storePayloads" but not "fetchPayloads", it would > also behave like it does now, but the unifiedpush will store the payloads. > Using "fetchPayloads" but not "storePayloads" would result into error on > the JS client side. > > So, what do you think? Also, if something is not clear, just ask. > > PS: Some of you might say that push notifications are not meant to carry > data. Well, the world is not always following the guidelines (also the GCM > is made [2] to deliver data and APNS is somehow in between as it allows > some data to be sent but not as much as GCM). > > 1 - > https://play.google.com/store/apps/details?id=com.brainwashstudio.dotekom... > 2 - http://developer.android.com/google/gcm/adv.html#payload > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >