> Date: Tue, 13 Nov 2012 07:30:34 +0000 > From: [email protected] > To: [email protected] > Subject: Re: [jdev] Help choosing the right technology > > Just to clear up a couple of things. > > On Tue, Nov 13, 2012 at 7:12 AM, Michael Weibel > <[email protected]> wrote: > >> Push based communication. > > Besides ejabberd commercial, I don't know which servers implement this. > > {SNIP} > > 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. > > {SNIP} > > /K You could do what MXit did back in the day and shorten element names. E.g.: - {jabber:client}message = {jabber:client}m (jabber:client is usually defined on the stream:stream element, so there isn't much point in shortening it)- {jabber:client}iq = {jabber:client}i- {jabber:iq:roster}query = {j:i:r}q- @from = @f- And so forth You should be able to do this at the XML emission/parsing layer through encapsulation or polymorphism (this should be a really simple hashtable lookup if your server/client of choice sees XML as data and not a string). If you care about interopability (which you should), it would likely be appropriate in the transport features section of the stream. S:<stream:features> <nameshortening xmlns='http://mycompany.com/xmpp/features' /> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <required/> </starttls> ...</stream:features> C:<optimize xmlns='http://mycompany.com/xmpp/features' /> S:<proceed xmlns='http://mycompany.com/xmpp/features' /> That way clients that don't understand it would simply skip past it and head directly to STARTTLS. Compression alone *should* be good enough, but I remember the MXit team indicating that they did get some clutch savings from doing this: even with compression. You could take it further by also omitting the 'from' attribute on the client (assume that the server will fill it in for you), and omitting the 'to' element if the communication is directly C->S or S->C (that would likely be an additional customization you would need to make, likely as part of 'nameshortening'). Taking all of that into consideration we can shorten this:<message from='[email protected]' to='[email protected]' xml:lang='en'><body>Art thou not Romeo, and a Montague?</body></message> (130 characters)to this:<m t='[email protected]' xml:lang='en'><b>Art thou not Romeo, and a Montague?</b></m> (85 characters, 65% of the length) XEP-0286<http://xmpp.org/extensions/xep-0286.html> has some really nice recommendations. Without compression, a few simple tricks like that will comfortably get you out of the 128 octet FACH threshold. With compression you should be able to send a fair amount of data comfortably. As always, though, test it out before committing to it - it may not be worth the additional interopability headaches. -- Jonathan Dickinson
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
