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?
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev