On Fri Nov 9 18:37:08 2007, Rachel Blackman wrote:
If we like to chant the 'XMPP is not really XML' mantra and the 'we
must shave off every byte we can to spare the poor mobile users'
mantras, that's great.
I'm not chanting any mantras, sorry. If encrypted sessions become the
rule, rather than the rare exception - and I do want this to happen -
then 25% of a server owner's bandwidth bill is going to be down to
base64. If you're okay with that, please send me the cash instead. :-)
But considering we only have 3 actual main stanza types, a
purely binary (and not necessarily XML-related) protocol would be
more efficient.
Much harder to code and debug, though - we need a middle ground here.
An escape mechanism makes sense to me, but I'm easy to persuade
otherwise.
And if we're going to break the world by changing how XMPP
parsing works, then why on earth would we go through the pain of
breaking our protocol to glue the ability to include a few extra
characters in just to go ASCII85 or BASE91 instead of BASE64?
This I definitely agree with, not least because it still doesn't gain
us anything particularly useful in terms of bandwidth improvements.
We might drop that overhead from 33% to 10% with a serious amount of
work, but that's as good as it gets, and means introducing
tricky-to-write untested codecs everywhere. Fun and games.
I think we've lost sight of whatever the original problem we were
trying to solve was (inline images? Size of binary blobs to
mobiles?) and have become caught up in hypothetical solutions
which may no longer be directly connected to the issue. :)
The problem is hypothetical, which makes solutions also hypothetical.
The hypothesis is:
XMPP will display a tendency toward being used increasingly for
binary data, in particular via encryption, but also for various other
things (including file transfer). As this trend continues, the issue
of base64 encoding will play a significant role in bandwidth figures
for both servers and clients. This trend is desirable, because it
indicates an uptake of encryption, and therefore is to be encouraged
by support within the protocol.
Inlined images aren't driving this for me at all. At best it seems
that addressing these if we can has merit. I'm really thinking in
terms of IBB, and leveraging that for use in encrypted session
support et al ready for the future when we'll actually need this.
I'm entirely cool with agreeing it's not needed now, but the sooner
we start thinking about this the better - I think you're clearly
stating that if we choose to address this, it'll be a major bit of
work.
Please don't consider this in terms of inlined images and fringe
users - think of it in terms of ubiquitous encryption and servers.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
