+1


On Fri, Sep 27, 2013 at 2:30 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:

On Sep 27, 2013, at 7:55 AM, Kris Borchers <kris@redhat.com> wrote:

There is already work being done to look into handling "batch" messaging for SimplePush. It's easier for SimplePush because we control the push network so we can add that type of functionality. For the other networks though, if they can't accept multiple push messages in a single batch, you're still going to have to loop over them all and do those sends. With that in mind, IMO this should only be added if the push networks can handle it. Otherwise, this idea seems like it is going to muddy the waters in terms of mixing business logic into the UP server which we definitely don't want to do.
+1, no mixing


Again, IMO, if you are sending out several hundred thousand personalized messages via push, you're probably doing it wrong and need to reconsider the way your app is structured. Push messaging is not a mass e-mail system.

exactly


On Sep 27, 2013, at 2:12 AM, Apostolos Emmanouilidis <aemmanou@redhat.com> wrote:

I received some feedback for the aerogear-unifiedpush-server.

The case is:

Company X would like to create a personalized push notifications campaign for Y hundred thousands customers/clients. Personalized means that each client/device should receive a unique message. The messages are automatically produced from rules defined in a CRM system, but this is something which doesn't affect our implementation.

Currently, our selective send method is able to send one message to a selected list of clients. In cases like the above one, this translates into Y hundred thousands calls of the aerogear-unifiedpush-server selective send method. The question is whether we could change the signature of the selective send method and allow to pass an array of messages or not.

In my understanding, the advantages/disadvantages of a such change are similar to the advantages/disadvantages of a service according its level of granularity.

Fine Grained
+ simplicity and less business logic on server side
+ less amount of data exchanged between client/server
- a lot of interactions between client/server
- more interactions = more network overhead
- complex client side

Coarse Grained
+ less interactions between client/server
+ less network overhead & possibility of re-using the same network connection to send messages to the Push Networks (at least for APN)
+ simple client side
- much data exchanged in each interaction between client/server
- complex server side
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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