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> 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> 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> wrote:
>
>>
>>
>>
>> On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)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>
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> 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>
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> wrote:
>>>> +1 I agree that it makes sense to remove broadcast now.
>>>>
>>>>
>>>> On 13 September 2013 09:35, Matthias Wessendorf <matzew(a)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
>>>>
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