ubuntu-push-devs team mailing list archive

[Ted Gould <ted@xxxxxxxx>]

On Wed, 2013-09-25 at 14:53 -0300, Lucio Torre wrote:
> Although i have a bias against erlang and xml i am looking into
> ejabberd for this.
> 

Great, thanks for looking into it!

> The first thing that one notices is how suited it seems to be to the
> problem by the technical description and marketing material:
> 
> 
>       * Push notification capability with alerts sent to end-user’s
>         mobile device via push notification systems like APNS and
>         Google respectively provided by Apple and Google. If end
>         user’s mobile app is not running in the foreground/background,
>         an alert is sent each time a message is received via push
>         feature.
>       * http://www.process-one.net/en/ejabberd/
>         
> 
> 
> But going deeper into the docs and specifications i've found two
> issues that worry me: reliability of delivery and storage.
> 
> 
> Storage: Ejabberd uses mnesia or odbc/mysql/postgres for storage of
> messages. Scaling and balancing this is a pain point.

Hmm, perhaps it would be best to look at a different XMPP implementation
then?   I guess storage seems like something different ones would do
differently.  I guess that would require choosing to use XMPP, deciding
what features we need, and then deciding which servers we could use
(possibly modify) to solve our requirements.  I'm guessing the largest
deployments are using their own custom servers though.

> Reliability of delivery: The XMPP Core spec says:

Perhaps this my misunderstanding of the low level goal here, but I
thought we were trying to leave the radios off as much as possible.  And
it seems to me, that means no long running TCP connections as you don't
want to have the radios on.  But the benefit you get from a push
implementation is that there is only one service on the phone that is
either bringing up the radios or are using them opportunistically.

That would mean the mechanism is largely bases on connecting, grabbing
queued messages, and perhaps based on heuristics leaving the connection
open for a bit of time.  So any issues regarding long running TCP
connections are mostly moot.

Ted

Attachment: signature.asc
Description: This is a digitally signed message part