+1 I agree that it makes sense to remove broadcast now. On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Following up on [1], to catch a wider audience, than JIRA. > > I do agree that it feels odd, for SimplePush. > > -M > > [1] https://issues.jboss.org/browse/AGPUSH-323 > > -- > 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

What is the reasoning behind this, i think i missed something On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Concretely what does that means ? removing "simple-push" field from the broadcast message ? > The jira mention that we can achieve the same with a selective send but on the client side when I want to send a broadcast and being agnostic from the receiving clients I still want to use the (Unified) broadcast format. > So my question is will SimplePush Clients still receive my message if I broadcast it (and not using the selective send) ? > > > > > On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >> +1 I agree that it makes sense to remove broadcast now. >> >> >> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> Following up on [1], to catch a wider audience, than JIRA. >>> >>> I do agree that it feels odd, for SimplePush. >>> >>> -M >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>> >>> -- >>> 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

Yes but again when you want to do a broadcast to all the devices types and broadcast is not anymore available for SPS, does that mean that we must send 2 messages : one broadcast for "native" clients and a "empty" selective send for SPS , not sure this is effective ? I must be missing something. On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: > The reasoning was that a broadcast can be done via selective if you just > send to a category and don't list any specific endpoints. To do a > broadcast, you specifically have to register a broadcast endpoint but then > your category doesn't have any meaning so it seems like more loss than gain > IMO. > > On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > What is the reasoning behind this, i think i missed something > On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > Concretely what does that means ? removing "simple-push" field from the > broadcast message ? > The jira mention that we can achieve the same with a selective send but > on the client side when I want to send a broadcast and being agnostic from > the receiving clients I still want to use the (Unified) broadcast format. > So my question is will SimplePush Clients still receive my message if I > broadcast it (and not using the selective send) ? > > > > > On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius < > daniel.bevenius(a)gmail.com&gt; wrote: > >> +1 I agree that it makes sense to remove broadcast now. >> >> >> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> Following up on [1], to catch a wider audience, than JIRA. >>> >>> I do agree that it feels odd, for SimplePush. >>> >>> -M >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>> >>> -- >>> 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

The reasoning was that a broadcast can be done via selective if you just send to a category and don't list any specific endpoints. To do a broadcast, you specifically have to register a broadcast endpoint but then your category doesn't have any meaning so it seems like more loss than gain IMO.

On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: What is the reasoning behind this, i think i missed something On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: Concretely what does that means ? removing "simple-push" field from the broadcast message ? The jira mention that we can achieve the same with a selective send but on the client side when I want to send a broadcast and being agnostic from the receiving clients I still want to use the (Unified) broadcast format. So my question is will SimplePush Clients still receive my message if I broadcast it (and not using the selective send) ? On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius < daniel.bevenius(a)gmail.com&gt; wrote: > +1 I agree that it makes sense to remove broadcast now. > > > On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > >> Following up on [1], to catch a wider audience, than JIRA. >> >> I do agree that it feels odd, for SimplePush. >> >> -M >> >> [1] https://issues.jboss.org/browse/AGPUSH-323 >> >> -- >> 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

On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Yes but again when you want to do a broadcast to all the devices types and broadcast is not anymore available for SPS, does that mean that we must send 2 messages : one broadcast for "native" clients and a "empty" selective send for SPS , not sure this is effective ? I must be missing something. that's a good point It would be two request to the UnifiedPush Server: * broadcast for Android/iOS * 'selective' send for the SimplePush client I guess having the implicit 'broadcast' category does not hurt, since this (as it is today) allows sending the broadcast to _all_ platforms via one request I think this does make sense. I think (and I had similar thoughts) that Kris thinks the 'explicit' (JS client side) registration for the broadcast category seems odd; But now, after some more thoughts, I think it's a feature and we should keep it > > > > On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: >> The reasoning was that a broadcast can be done via selective if you just send to a category and don't list any specific endpoints. To do a broadcast, you specifically have to register a broadcast endpoint but then your category doesn't have any meaning so it seems like more loss than gain IMO. >> >> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> What is the reasoning behind this, i think i missed something >>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> Concretely what does that means ? removing "simple-push" field from the broadcast message ? >>>> The jira mention that we can achieve the same with a selective send but on the client side when I want to send a broadcast and being agnostic from the receiving clients I still want to use the (Unified) broadcast format. >>>> So my question is will SimplePush Clients still receive my message if I broadcast it (and not using the selective send) ? >>>> >>>> >>>> >>>> >>>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >>>>> +1 I agree that it makes sense to remove broadcast now. >>>>> >>>>> >>>>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>> Following up on [1], to catch a wider audience, than JIRA. >>>>>> >>>>>> I do agree that it feels odd, for SimplePush. >>>>>> >>>>>> -M >>>>>> >>>>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>>>> >>>>>> -- >>>>>> 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 > > > _______________________________________________ > 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

You can do the same thing with the other platforms as with SimplePush, no? Won't it work the same way by sending a selective send that includes all necessary info for android, iOS and SimplePush but don't specify any particular devices and just a category, you then get a broadcast to all devices of all types for that category, correct? That is why I think the broadcast is pointless.

On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > Yes but again when you want to do a broadcast to all the devices types > and broadcast is not anymore available for SPS, does that mean that we must > send 2 messages : one broadcast for "native" clients and a "empty" > selective send for SPS , not sure this is effective ? I must be missing > something. > that's a good point It would be two request to the UnifiedPush Server: * broadcast for Android/iOS * 'selective' send for the SimplePush client I guess having the implicit 'broadcast' category does not hurt, since this (as it is today) allows sending the broadcast to _all_ platforms via one request I think this does make sense. I think (and I had similar thoughts) that Kris thinks the 'explicit' (JS client side) registration for the broadcast category seems odd; But now, after some more thoughts, I think it's a feature and we should keep it > > > > On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: > >> The reasoning was that a broadcast can be done via selective if you just >> send to a category and don't list any specific endpoints. To do a >> broadcast, you specifically have to register a broadcast endpoint but then >> your category doesn't have any meaning so it seems like more loss than gain >> IMO. >> >> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> What is the reasoning behind this, i think i missed something >> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >> Concretely what does that means ? removing "simple-push" field from the >> broadcast message ? >> The jira mention that we can achieve the same with a selective send but >> on the client side when I want to send a broadcast and being agnostic from >> the receiving clients I still want to use the (Unified) broadcast format. >> So my question is will SimplePush Clients still receive my message if I >> broadcast it (and not using the selective send) ? >> >> >> >> >> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius < >> daniel.bevenius(a)gmail.com&gt; wrote: >> >>> +1 I agree that it makes sense to remove broadcast now. >>> >>> >>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>> >>>> Following up on [1], to catch a wider audience, than JIRA. >>>> >>>> I do agree that it feels odd, for SimplePush. >>>> >>>> -M >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>> >>>> -- >>>> 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 >> > > > _______________________________________________ > 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

On Sep 19, 2013, at 6:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: > You can do the same thing with the other platforms as with SimplePush, > no? Won't it work the same way by sending a selective send that includes > all necessary info for android, iOS and SimplePush but don't specify any > particular devices and just a category, you then get a broadcast to all > devices of all types for that category, correct? That is why I think the > broadcast is pointless. > Your point is to remove for all platforms, or just for SimplePush ? Assuming a "broadcast" can be sent via a selective send in the other platforms like it can in SimplePush, I would like it removed everywhere. This would simplify the entire concept and the docs would only have to explain how to send, rather than how to selective send and how to broadcast.

According to these docs http://aerogear.org/docs/specs/aerogear-push-messages/ under Selective Send/Message Format/Query Component, it is possible which is what led me to this in the first place. > > On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > > On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: > >> Yes but again when you want to do a broadcast to all the devices types >> and broadcast is not anymore available for SPS, does that mean that we must >> send 2 messages : one broadcast for "native" clients and a "empty" >> selective send for SPS , not sure this is effective ? I must be missing >> something. >> > > that's a good point > > It would be two request to the UnifiedPush Server: > * broadcast for Android/iOS > * 'selective' send for the SimplePush client > > I guess having the implicit 'broadcast' category does not hurt, since > this (as it is today) allows sending the broadcast to _all_ platforms via > one request > > I think this does make sense. > > I think (and I had similar thoughts) that Kris thinks the 'explicit' (JS > client side) registration for the broadcast category seems odd; > > But now, after some more thoughts, I think it's a feature and we should > keep it > > > >> >> >> >> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: >> >>> The reasoning was that a broadcast can be done via selective if you >>> just send to a category and don't list any specific endpoints. To do a >>> broadcast, you specifically have to register a broadcast endpoint but then >>> your category doesn't have any meaning so it seems like more loss than gain >>> IMO. >>> >>> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>> >>> What is the reasoning behind this, i think i missed something >>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> >>> Concretely what does that means ? removing "simple-push" field from the >>> broadcast message ? >>> The jira mention that we can achieve the same with a selective send but >>> on the client side when I want to send a broadcast and being agnostic from >>> the receiving clients I still want to use the (Unified) broadcast format. >>> So my question is will SimplePush Clients still receive my message if I >>> broadcast it (and not using the selective send) ? >>> >>> >>> >>> >>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius < >>> daniel.bevenius(a)gmail.com&gt; wrote: >>> >>>> +1 I agree that it makes sense to remove broadcast now. >>>> >>>> >>>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>>> >>>>> Following up on [1], to catch a wider audience, than JIRA. >>>>> >>>>> I do agree that it feels odd, for SimplePush. >>>>> >>>>> -M >>>>> >>>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>>> >>>>> -- >>>>> 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 >>> >> >> >> _______________________________________________ >> 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 > -- 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

On Thu, Sep 19, 2013 at 1:44 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Sep 19, 2013, at 6:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: > You can do the same thing with the other platforms as with SimplePush, no? Won't it work the same way by sending a selective send that includes all necessary info for android, iOS and SimplePush but don't specify any particular devices and just a category, you then get a broadcast to all devices of all types for that category, correct? That is why I think the broadcast is pointless. > > Your point is to remove for all platforms, or just for SimplePush ? Assuming a "broadcast" can be sent via a selective send in the other platforms like it can in SimplePush, I would like it removed everywhere. This would simplify the entire concept and the docs would only have to explain how to send, rather than how to selective send and how to broadcast. these are fair points. I think the broadcast (currently ;-)) is there, since that's what we started with. We added more and more criteria later on. I think I saw it as a convenience until now, but yeah... simplifying docs did buy it for me :-) Let's wait for more comments, but this might be implemented for the next release.

-M According to these docs http://aerogear.org/docs/specs/aerogear-push-messages/ under Selective Send/Message Format/Query Component, it is possible which is what led me to this in the first place. > > > > On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> Yes but again when you want to do a broadcast to all the devices types and broadcast is not anymore available for SPS, does that mean that we must send 2 messages : one broadcast for "native" clients and a "empty" selective send for SPS , not sure this is effective ? I must be missing something. >> >> that's a good point >> >> It would be two request to the UnifiedPush Server: >> * broadcast for Android/iOS >> * 'selective' send for the SimplePush client >> >> I guess having the implicit 'broadcast' category does not hurt, since this (as it is today) allows sending the broadcast to _all_ platforms via one request >> >> I think this does make sense. >> >> I think (and I had similar thoughts) that Kris thinks the 'explicit' (JS client side) registration for the broadcast category seems odd; >> >> But now, after some more thoughts, I think it's a feature and we should keep it >> >> >> >> >> >> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt; wrote: >> The reasoning was that a broadcast can be done via selective if you just send to a category and don't list any specific endpoints. To do a broadcast, you specifically have to register a broadcast endpoint but then your category doesn't have any meaning so it seems like more loss than gain IMO. >> >> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> What is the reasoning behind this, i think i missed something >>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>>> Concretely what does that means ? removing "simple-push" field from the broadcast message ? >>>> The jira mention that we can achieve the same with a selective send but on the client side when I want to send a broadcast and being agnostic from the receiving clients I still want to use the (Unified) broadcast format. >>>> So my question is will SimplePush Clients still receive my message if I broadcast it (and not using the selective send) ? >>>> >>>> >>>> >>>> >>>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: >>>> +1 I agree that it makes sense to remove broadcast now. >>>> >>>> >>>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> Following up on [1], to catch a wider audience, than JIRA. >>>> >>>> I do agree that it feels odd, for SimplePush. >>>> >>>> -M >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>> >>>> -- >>>> 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 >> >> >> _______________________________________________ >> 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 > > > > -- > 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 -- 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

On Sep 19, 2013, at 7:04 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: I'm +1 to simplify it and regarding refactoring on the client side I assume it will be just having a better name that we have now (sendTo) https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/... . And in a first time to make the move a bit smoother we could just mark rhe broadcast method as deprecated. Since we are still not at 1.0, IMO deprecation is not necessary. We can just change at will until we have a stable release.

On Thu, Sep 19, 2013 at 1:53 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Thu, Sep 19, 2013 at 1:44 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Sep 19, 2013, at 6:39 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: >> >>> You can do the same thing with the other platforms as with SimplePush, >>> no? Won't it work the same way by sending a selective send that includes >>> all necessary info for android, iOS and SimplePush but don't specify any >>> particular devices and just a category, you then get a broadcast to all >>> devices of all types for that category, correct? That is why I think the >>> broadcast is pointless. >>> >> >> Your point is to remove for all platforms, or just for SimplePush ? >> >> >> Assuming a "broadcast" can be sent via a selective send in the other >> platforms like it can in SimplePush, I would like it removed everywhere. >> This would simplify the entire concept and the docs would only have to >> explain how to send, rather than how to selective send and how to >> broadcast. >> > > these are fair points. > > I think the broadcast (currently ;-)) is there, since that's what we > started with. We added more and more criteria later on. > > I think I saw it as a convenience until now, but yeah... simplifying docs > did buy it for me :-) > > > Let's wait for more comments, but this might be implemented for the next > release. > > -M > > > >> According to these docs >> http://aerogear.org/docs/specs/aerogear-push-messages/ under Selective >> Send/Message Format/Query Component, it is possible which is what led me to >> this in the first place. >> >> >> >> >> >>> >>> On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> >>> On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt;wrote: >>> >>>> Yes but again when you want to do a broadcast to all the devices types >>>> and broadcast is not anymore available for SPS, does that mean that we must >>>> send 2 messages : one broadcast for "native" clients and a "empty" >>>> selective send for SPS , not sure this is effective ? I must be missing >>>> something. >>>> >>> >>> that's a good point >>> >>> It would be two request to the UnifiedPush Server: >>> * broadcast for Android/iOS >>> * 'selective' send for the SimplePush client >>> >>> I guess having the implicit 'broadcast' category does not hurt, since >>> this (as it is today) allows sending the broadcast to _all_ platforms via >>> one request >>> >>> I think this does make sense. >>> >>> I think (and I had similar thoughts) that Kris thinks the 'explicit' >>> (JS client side) registration for the broadcast category seems odd; >>> >>> But now, after some more thoughts, I think it's a feature and we should >>> keep it >>> >>> >>> >>>> >>>> >>>> >>>> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com&gt;wrote: >>>> >>>>> The reasoning was that a broadcast can be done via selective if you >>>>> just send to a category and don't list any specific endpoints. To do a >>>>> broadcast, you specifically have to register a broadcast endpoint but then >>>>> your category doesn't have any meaning so it seems like more loss than gain >>>>> IMO. >>>>> >>>>> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>> What is the reasoning behind this, i think i missed something >>>>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>> Concretely what does that means ? removing "simple-push" field from >>>>> the broadcast message ? >>>>> The jira mention that we can achieve the same with a selective send >>>>> but on the client side when I want to send a broadcast and being agnostic >>>>> from the receiving clients I still want to use the (Unified) broadcast >>>>> format. >>>>> So my question is will SimplePush Clients still receive my message if >>>>> I broadcast it (and not using the selective send) ? >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius < >>>>> daniel.bevenius(a)gmail.com&gt; wrote: >>>>> >>>>>> +1 I agree that it makes sense to remove broadcast now. >>>>>> >>>>>> >>>>>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>>>>> >>>>>>> Following up on [1], to catch a wider audience, than JIRA. >>>>>>> >>>>>>> I do agree that it feels odd, for SimplePush. >>>>>>> >>>>>>> -M >>>>>>> >>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > 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

On Thu, Sep 19, 2013 at 07:24:31AM -0500, Kris Borchers wrote: > Since we are still not at 1.0, IMO deprecation is not necessary. We > can just change at will until we have a stable release. +1 -- qmx_______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: You can do the same thing with the other platforms as with SimplePush, no? Won't it work the same way by sending a selective send that includes all necessary info for android, iOS and SimplePush but don't specify any particular devices and just a category, you then get a broadcast to all devices of all types for that category, correct? That is why I think the broadcast is pointless. Your point is to remove for all platforms, or just for SimplePush ? On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc > <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: > > Yes but again when you want to do a broadcast to all the > devices types and broadcast is not anymore available for SPS, > does that mean that we must send 2 messages : one broadcast > for "native" clients and a "empty" selective send for SPS , > not sure this is effective ? I must be missing something. > > > that's a good point > > It would be two request to the UnifiedPush Server: > * broadcast for Android/iOS > * 'selective' send for the SimplePush client > > I guess having the implicit 'broadcast' category does not hurt, > since this (as it is today) allows sending the broadcast to _all_ > platforms via one request > > I think this does make sense. > > I think (and I had similar thoughts) that Kris thinks the > 'explicit' (JS client side) registration for the broadcast > category seems odd; > > But now, after some more thoughts, I think it's a feature and we > should keep it > > > > > > > On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers > <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: > > The reasoning was that a broadcast can be done via > selective if you just send to a category and don't list > any specific endpoints. To do a broadcast, you > specifically have to register a broadcast endpoint but > then your category doesn't have any meaning so it seems > like more loss than gain IMO. > > On Sep 13, 2013, at 7:11, Lucas Holmquist > <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: > >> What is the reasoning behind this, i think i missed >> something >> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc >> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >> >>> Concretely what does that means ? removing >>> "simple-push" field from the broadcast message ? >>> The jira mention that we can achieve the same with a >>> selective send but on the client side when I want to >>> send a broadcast and being agnostic from the receiving >>> clients I still want to use the (Unified) broadcast >>> format. >>> So my question is will SimplePush Clients still receive >>> my message if I broadcast it (and not using the >>> selective send) ? >>> >>> >>> >>> >>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius >>> <daniel.bevenius(a)gmail.com >>> <mailto:daniel.bevenius@gmail.com>> wrote: >>> >>> +1 I agree that it makes sense to remove broadcast now. >>> >>> >>> On 13 September 2013 09:35, Matthias Wessendorf >>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>> >>> Following up on [1], to catch a wider audience, >>> than JIRA. >>> >>> I do agree that it feels odd, for SimplePush. >>> >>> -M >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>> >>> -- >>> 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 >>> <mailto:aerogear-dev@lists.jboss.org> >>> 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 >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@lists.jboss.org> >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@lists.jboss.org> > 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 > > > > > -- > 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 <mailto:aerogear-dev@lists.jboss.org> > 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 -- 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

JR, I'm a little confused by your question but let me give you a little background on this thread. First, we have what we call our UnifiedPush Server which to keep the explanation short, aggregates the sending of push messages to different networks (APNs, GCM, SimplePush) into a single POST request with a single JSON payload. You register applications with this server, then create variants for that app, usually into one for each network but could also be furthered fragmented into paid and free apps, etc, and then devices register with a variant and in the case of SimplePush, each endpoint is treated as a different device for simplicity. Early in development, we implemented a special send type called 'broadcast' which would allow for sending to an entire application (all devices for all variants). This issue/discussion is about removing that broadcast type because we can do the same thing with our regular send functionality by not specifying certain criteria like device id's etc. Does that make sense? If so and your question still stands, could you elaborate? On Sep 19, 2013, at 10:39 AM, JR Conlin <jrconlin(a)gmail.com <mailto:jrconlin@gmail.com>> wrote: > I'm a bit late to this, but I'm also a little curious. > > Are you planning on using SimplePush the way you'd use any data > delivery channel? (e.g. for a given message event, you'd include a > SimplePush remote app wake event?) > > If so, that might not be the more efficient means. > > On 2013/9/19 4:39 AM, Matthias Wessendorf wrote: >> >> >> >> On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com >> <mailto:kborcher@redhat.com>> wrote: >> >> You can do the same thing with the other platforms as with >> SimplePush, no? Won't it work the same way by sending a >> selective send that includes all necessary info for android, iOS >> and SimplePush but don't specify any particular devices and just >> a category, you then get a broadcast to all devices of all types >> for that category, correct? That is why I think the broadcast is >> pointless. >> >> >> Your point is to remove for all platforms, or just for SimplePush ? >> >> >> >> >> On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org >> <mailto:matzew@apache.org>> wrote: >> >>> >>> >>> >>> On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc >>> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >>> >>> Yes but again when you want to do a broadcast to all the >>> devices types and broadcast is not anymore available for >>> SPS, does that mean that we must send 2 messages : one >>> broadcast for "native" clients and a "empty" selective send >>> for SPS , not sure this is effective ? I must be missing >>> something. >>> >>> >>> that's a good point >>> >>> It would be two request to the UnifiedPush Server: >>> * broadcast for Android/iOS >>> * 'selective' send for the SimplePush client >>> >>> I guess having the implicit 'broadcast' category does not hurt, >>> since this (as it is today) allows sending the broadcast to >>> _all_ platforms via one request >>> >>> I think this does make sense. >>> >>> I think (and I had similar thoughts) that Kris thinks the >>> 'explicit' (JS client side) registration for the broadcast >>> category seems odd; >>> >>> But now, after some more thoughts, I think it's a feature and >>> we should keep it >>> >>> >>> >>> >>> >>> >>> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers >>> <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: >>> >>> The reasoning was that a broadcast can be done via >>> selective if you just send to a category and don't list >>> any specific endpoints. To do a broadcast, you >>> specifically have to register a broadcast endpoint but >>> then your category doesn't have any meaning so it seems >>> like more loss than gain IMO. >>> >>> On Sep 13, 2013, at 7:11, Lucas Holmquist >>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: >>> >>>> What is the reasoning behind this, i think i missed >>>> something >>>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc >>>> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >>>> >>>>> Concretely what does that means ? removing >>>>> "simple-push" field from the broadcast message ? >>>>> The jira mention that we can achieve the same with a >>>>> selective send but on the client side when I want to >>>>> send a broadcast and being agnostic from the >>>>> receiving clients I still want to use the (Unified) >>>>> broadcast format. >>>>> So my question is will SimplePush Clients still >>>>> receive my message if I broadcast it (and not using >>>>> the selective send) ? >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius >>>>> <daniel.bevenius(a)gmail.com >>>>> <mailto:daniel.bevenius@gmail.com>> wrote: >>>>> >>>>> +1 I agree that it makes sense to remove >>>>> broadcast now. >>>>> >>>>> >>>>> On 13 September 2013 09:35, Matthias Wessendorf >>>>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>>>> >>>>> Following up on [1], to catch a wider >>>>> audience, than JIRA. >>>>> >>>>> I do agree that it feels odd, for SimplePush. >>>>> >>>>> -M >>>>> >>>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>>> >>>>> -- >>>>> 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 >>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>> 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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@lists.jboss.org> >>> 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 >>> >>> >>> >>> >>> -- >>> 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 <mailto:aerogear-dev@lists.jboss.org> >>> 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 >> >> >> >> >> -- >> 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 <mailto:aerogear-dev@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

Yeah, I think this was just a misunderstanding. See comments inline. On Sep 19, 2013, at 12:04 PM, JR Conlin <jrconlin(a)gmail.com <mailto:jrconlin@gmail.com>> wrote: > I think I follow, and perhaps I should also provide a bit of insight > about how SimplePush was designed. > > For mobile devices, what really kills the battery is maintaining lots > of sockets. Honestly, maintaining even one socket prevents the CPU > from sleeping, and that's one of the big reasons that mobile phones > don't last anywhere near as long as wifi only mobile devices. Still, > if we could get a single socket, there's far less CPU involved and > that helps as well. Plus the "proprietary" stuff allows carriers to > use various back-door things to wake phones without maintaining a > network connection. > > In addition, SimplePush is data free. Yes, there's a "version" > associated with it, but even that was seriously considered something > we should replace with a second based timestamp. There are a lot of > reasons for this (user privacy, back end can't be subpoenaed for > useful information by governments, statelessness on servers is a > wonderful thing, etc.) Yep, we totally get this. In fact, in any examples I have thrown together, I usually just use a timestamp for the version and don't even check it client side. :) > > Think of SimplePush as a doorbell. Apps can use it to wake up a > remote app and have it connect back. There's loss, and potentially > some lag around the doorbell, but it works fairly well (we hope). > Still imagine having a conversation where every sentence, the person > walks back to the doorbell presses the button waits for you to > acknowledge it, and then begins speaking. Not really the best experience. Again, we get this. > > What makes a better experience is for Apps to see if a given client > is connected, and if not, use the SimplePush system to remotely wake > the app and have it connect up again. At that point, the App and > Server have a far more efficient mechanism to communicate than > someone walking away to hit the doorbell again. Again ... > > I understand that your broadcast was for an app across devices. My > concern is that for things like chat applications, stock updates or > any other high message rate system, you may be sending a lot of > useless data and triggering a great many unneeded events in the > remote app. We are not sending the extra data along to SimplePush clients. That is part of what our UnifiedPush server does. It takes that payload, determines if there is SimplePush data, if so, it takes that SimplePush part of the payload (version=12345) and sends that off to the SimplePush server via the registered endpoints for each device. To be clear, UnifiedPush and SimplePush are separate servers in this model. Obviously, we can't stop an app developer if they want to send notifications to the devices all the time but we are set up in the way you describe, the app should only ping clients via SimplePush when necessary but otherwise use other means of data transfer. > > I hope that I'm just misunderstanding or unclear on this, and I > apologize if this is off-base. I've just learned that it's important > to try and get ahead of these sorts of things as early as I can so > that folks aren't screaming later. No need to apologize! We really appreciate any and all input you have!! > > On 2013/9/19 8:48 AM, Kris Borchers wrote: >> JR, I'm a little confused by your question but let me give you a >> little background on this thread. >> >> First, we have what we call our UnifiedPush Server which to keep the >> explanation short, aggregates the sending of push messages to >> different networks (APNs, GCM, SimplePush) into a single POST >> request with a single JSON payload. You register applications with >> this server, then create variants for that app, usually into one for >> each network but could also be furthered fragmented into paid and >> free apps, etc, and then devices register with a variant and in the >> case of SimplePush, each endpoint is treated as a different device >> for simplicity. Early in development, we implemented a special send >> type called 'broadcast' which would allow for sending to an entire >> application (all devices for all variants). This issue/discussion is >> about removing that broadcast type because we can do the same thing >> with our regular send functionality by not specifying certain >> criteria like device id's etc. >> >> Does that make sense? If so and your question still stands, could >> you elaborate? >> >> On Sep 19, 2013, at 10:39 AM, JR Conlin <jrconlin(a)gmail.com >> <mailto:jrconlin@gmail.com>> wrote: >> >>> I'm a bit late to this, but I'm also a little curious. >>> >>> Are you planning on using SimplePush the way you'd use any data >>> delivery channel? (e.g. for a given message event, you'd include a >>> SimplePush remote app wake event?) >>> >>> If so, that might not be the more efficient means. >>> >>> On 2013/9/19 4:39 AM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers >>>> <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: >>>> >>>> You can do the same thing with the other platforms as with >>>> SimplePush, no? Won't it work the same way by sending a >>>> selective send that includes all necessary info for android, >>>> iOS and SimplePush but don't specify any particular devices >>>> and just a category, you then get a broadcast to all devices >>>> of all types for that category, correct? That is why I think >>>> the broadcast is pointless. >>>> >>>> >>>> Your point is to remove for all platforms, or just for SimplePush ? >>>> >>>> >>>> >>>> >>>> On Sep 14, 2013, at 4:19, Matthias Wessendorf >>>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc >>>>> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> wrote: >>>>> >>>>> Yes but again when you want to do a broadcast to all the >>>>> devices types and broadcast is not anymore available for >>>>> SPS, does that mean that we must send 2 messages : one >>>>> broadcast for "native" clients and a "empty" selective >>>>> send for SPS , not sure this is effective ? I must be >>>>> missing something. >>>>> >>>>> >>>>> that's a good point >>>>> >>>>> It would be two request to the UnifiedPush Server: >>>>> * broadcast for Android/iOS >>>>> * 'selective' send for the SimplePush client >>>>> >>>>> I guess having the implicit 'broadcast' category does not >>>>> hurt, since this (as it is today) allows sending the >>>>> broadcast to _all_ platforms via one request >>>>> >>>>> I think this does make sense. >>>>> >>>>> I think (and I had similar thoughts) that Kris thinks the >>>>> 'explicit' (JS client side) registration for the broadcast >>>>> category seems odd; >>>>> >>>>> But now, after some more thoughts, I think it's a feature and >>>>> we should keep it >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers >>>>> <kborcher(a)redhat.com <mailto:kborcher@redhat.com>> wrote: >>>>> >>>>> The reasoning was that a broadcast can be done via >>>>> selective if you just send to a category and don't >>>>> list any specific endpoints. To do a broadcast, you >>>>> specifically have to register a broadcast endpoint >>>>> but then your category doesn't have any meaning so it >>>>> seems like more loss than gain IMO. >>>>> >>>>> On Sep 13, 2013, at 7:11, Lucas Holmquist >>>>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: >>>>> >>>>>> What is the reasoning behind this, i think i missed >>>>>> something >>>>>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc >>>>>> <scm.blanc(a)gmail.com <mailto:scm.blanc@gmail.com>> >>>>>> wrote: >>>>>> >>>>>>> Concretely what does that means ? removing >>>>>>> "simple-push" field from the broadcast message ? >>>>>>> The jira mention that we can achieve the same with >>>>>>> a selective send but on the client side when I want >>>>>>> to send a broadcast and being agnostic from the >>>>>>> receiving clients I still want to use the (Unified) >>>>>>> broadcast format. >>>>>>> So my question is will SimplePush Clients still >>>>>>> receive my message if I broadcast it (and not using >>>>>>> the selective send) ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius >>>>>>> <daniel.bevenius(a)gmail.com >>>>>>> <mailto:daniel.bevenius@gmail.com>> wrote: >>>>>>> >>>>>>> +1 I agree that it makes sense to remove >>>>>>> broadcast now. >>>>>>> >>>>>>> >>>>>>> On 13 September 2013 09:35, Matthias Wessendorf >>>>>>> <matzew(a)apache.org <mailto:matzew@apache.org>> >>>>>>> wrote: >>>>>>> >>>>>>> Following up on [1], to catch a wider >>>>>>> audience, than JIRA. >>>>>>> >>>>>>> I do agree that it feels odd, for SimplePush. >>>>>>> >>>>>>> -M >>>>>>> >>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-323 >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> <mailto:aerogear-dev@lists.jboss.org> >>>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> 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 <mailto:aerogear-dev@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 <mailto:aerogear-dev@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