[aerogear-dev] Remove SimplePush broadcast from Sender API
JR Conlin
jrconlin at gmail.com
Thu Sep 19 13:18:35 EDT 2013
Awesome!
I'll switch to decaf for a bit.
On 2013/9/19 10:15 AM, Kris Borchers wrote:
> Yeah, I think this was just a misunderstanding. See comments inline.
>
> On Sep 19, 2013, at 12:04 PM, JR Conlin <jrconlin at gmail.com
> <mailto:jrconlin at 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 at gmail.com
>>> <mailto:jrconlin at 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 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
>>>>
>>>> _______________________________________________
>>>> 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
>>> 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
> 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/ab54dd51/attachment-0001.html
More information about the aerogear-dev
mailing list