[aerogear-dev] Remove SimplePush broadcast from Sender API

JR Conlin jrconlin at gmail.com
Thu Sep 19 11:39:38 EDT 2013


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 at redhat.com
> <mailto:kborcher at 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 at apache.org
>     <mailto:matzew at apache.org>> wrote:
>
>>
>>
>>
>>     On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc
>>     <scm.blanc at gmail.com <mailto:scm.blanc at 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 at redhat.com <mailto:kborcher at 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 at redhat.com <mailto:lholmqui at 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 at gmail.com <mailto:scm.blanc at 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 at gmail.com
>>>>             <mailto:daniel.bevenius at gmail.com>> wrote:
>>>>
>>>>                 +1 I agree that it makes sense to remove broadcast now.
>>>>
>>>>
>>>>                 On 13 September 2013 09:35, Matthias Wessendorf
>>>>                 <matzew at apache.org <mailto:matzew at 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 at lists.jboss.org
>>>>                     <mailto:aerogear-dev at lists.jboss.org>
>>>>                     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 aerogear-dev mailing list
>>>>                 aerogear-dev at lists.jboss.org
>>>>                 <mailto:aerogear-dev at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>             _______________________________________________
>>>>             aerogear-dev mailing list
>>>>             aerogear-dev at lists.jboss.org
>>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>>             https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>             _______________________________________________
>>>             aerogear-dev mailing list
>>>             aerogear-dev at lists.jboss.org
>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>             _______________________________________________
>>             aerogear-dev mailing list
>>             aerogear-dev at lists.jboss.org
>>             <mailto:aerogear-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>         _______________________________________________
>>         aerogear-dev mailing list
>>         aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at 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 at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130919/1ecb30cf/attachment-0001.html 


More information about the aerogear-dev mailing list