ubuntu-push-devs team mailing list archive

[Peter Saint-Andre <stpeter@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ Joined late, replying to the first message I see. ]

On 10/1/13 11:38 AM, Ted Gould wrote:
> 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/

It seems to me that if you want a wake-up message, you'll need to use
the API/service that's provided by Apple or Google.

>> 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.

Yes.

> 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.

Generally not, other than Google.

>> 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.

My understanding from some mobile telephony engineers I talked with
years ago (folks from Nokia) is that mobile devices can actually deal
with long-running TCP connections quite well. There's magic involved.

> 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's the theory, anyway.

> 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.

Right.

I'm not necessarily pushing XMPP here because it's not the answer for
everything. However, there are good open-source implementations for
both servers and libraries. I'll spend some time digging into the list
archives here so that I can understand your requirements a bit better.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSS07VAAoJEOoGpJErxa2pWR8P/3u0UsB123OfvmMOADAQW4Ej
YKBxqOn1slck+Q54Ty3QZm5XD59Tyv1pG5mluO/oXyEB7Gj8j5/iHV3D8ORYTvz/
6cau+igkQK9NCrOCpEMGlX3kMvm+5sBqhit503p2jk9v/QCBvz4Yj0v2N536YOTz
MPn49E9rARhlLmwylaDMgQQL0qtQ1uVDaWF/b+dgxSMxUyxs4bUVlzS8Kd08lkrJ
HU7CJl10po+n7p83t4R9z1ClgmCrlUWV1DkSo7nu3eKK/4K7/2SDOPZlDj5VQbQE
JenQoFAMuFhSVNUmAI5BB9ivLrsGgiebuGCz6R0BEAtEHNgcrkMj/NMZjuhabmzT
7MLgCCDWPN1dRA0Eal6X88+jaXHYhNL+OHusw3BsatgxXABf/rnnaOV47p+PSzxV
G+J9xEO3964rafOwddRS/eBvTbIzMmtFyeBVQ/wMSgTeJO5ORk37pAJo2hcY4j2+
nDqfzRDBVd1s+Rpq3jP/MoQ3vgZh5zFgi1Xfr+2sCsjFi9+5ns7QixSffaOC0ob1
gCeyJGaGqntp1W8BhvbHqnPQ+B/sfY4kZsimLXA0EXv+5vXzxl8yOFvKuKA6jGU7
CCssyzjS0pJ1MhPPz15MuuJiDrvR7VOpdkg6RELUYQgwIwGu4yQUJ9f85S2WdiB2
zliwm3xYy0+OlQImN8hm
=o2ED
-----END PGP SIGNATURE-----