[jdev] Help choosing the right technology

[andy nes]

*@Michael*
Thank you for the XEP numbers. Will have a look.

*@Obaid*
Info on Message Delivery is good enough to go ahead. So if a user
accidentally goes offline and comes back, will the missed message be
delivered? Is it inbuilt behavior or should implement any XEP?

Ping sounds good enough.

*@Kevin*
We chose ejabberd as server, heard good things about it's scalability.
Regd. Libraries, is there any other good library for android other than
aSmack?

*@ALL*
While I was researching, I read a lot about AMQP as a possible alternative
for XMPP, saying that it is much more effective since there is no XML and
rosters. Want to hear your opinion about AMQP in my application's context
(real time tracking, machine-machine and machine-man commuication)

regards,
andy


On Tue, Nov 13, 2012 at 1:00 PM, Kevin Smith <kevin at kismith.co.uk> wrote:

> Just to clear up a couple of things.
>
> On Tue, Nov 13, 2012 at 7:12 AM, Michael Weibel
> <michael.weibel+xmpp at gmail.com> wrote:
> >> Push based communication.
> > Besides ejabberd commercial, I don't know which servers implement this.
>
> All XMPP servers provide 'push' communication. Presence and message
> stanzas are push-based, iq are polling.
>
> >> Guaranteed message delivery
> > This is one of the most important things for mobile (as you might know
> already). There's XEP-184[1] for this and you have to watch out that your
> server implements this in order to know that the server really received
> this message.
> > Besides this XEP there exist different implementations by some servers.
>
> 184 is client-to-client. XEP-0198 is the client-server one.
>
> >> Scalability
> > This entirely depends on the server and, more specifically on your use
> case. You might want to do load tests using e.g. Tsung[2].
>
> Picking an arbitrary load testing tool is unlikely to result in useful
> data. The best thing is to quickly knock together a tool that
> simulates the type of traffic you'll be generating.
>
> But yes, some XMPP servers scale well.
>
> >> Machine to Machine communication
> > What do you mean with this? XMPP is a federated protocol, therefore S2S
> communication is builtin.
>
> There's no problem writing non-human-driven XMPP clients. Just pick a
> library and off you go. XMPP isn't a chat system at its core, it's a
> way of routing snippets of data.
>
> >> Mobile friendly
> > XML is considered verbose. You can enable stream compression if the
> server supports it. On the last XMPP Summit they talked about XML->JSON
> translating which might help to reduce verbosity.
>
> JSON/XML is pretty much a red herring here - to encode the same data
> you're just switching <> for {}.
>
> But XMPP stanzas aren't /that/ big before transmission, when you're
> talking about working over phone networks. Yes, compression will help
> with stanza size.
>
> >> always on
> > I don't know what you mean with this, can you elaborate?
>
> You can open a connection and leave it open. Yes, this is the model
> XMPP uses (as opposed to HTTP, which uses many requests over time).
>
> >> Is XMPP good to build a Mobile app?
> >
> > Message reliability is very important (as said previously). Also you'll
> need an XMPP library which is robust. There's e.g. asmack[3] for Android
> and e.g. XMPPFramework[4] for iOS.
>
> There are more choices than just these (and these may not be the best
> choices).
>
> /K
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20121113/ef9e8aa5/attachment.html>