Peter Saint-Andre wrote:
Boyd Fletcher wrote:*SNIP*As far as I understand it, Efficient XML is more than just a compression algorithm. In order to prevent developer confusion, I think it might be helpful to write a XEP that describes how Efficient XML is to be used in the context of XMPP applications. That XEP could also register an item to be added to the compression algorithms registry. /psa
I like EXI, I really do, but how well will it work with streaming? EXI, in full, looks like it's designed for transactional requests, like SOAP, where the entire message is encoded at once. Maybe there should be a 'fixed' event tree for Jabber gathered from statistics from a popular server (j.o seems like a good place to start).
Only sending the header at the stream start seems like a good idea, but I would be tempted to send it with every stanza if it's not stated clearly (it would probably be the default behaviour for most EXI libraries). I really think EXI is a good idea, but it's open to so many ambiguities.
EXI is pretty open to including custom options like this. Because it's binary I think the XEP will have to be really clear about ambiguities: textual XML is harder to mess up. Binary stuff can go nuts.
I think we were lucky as far as XML libraries go (e.g. expat). They were not designed for XMPP, but they could be used for it anyway. I think we are going to have a harder time finding EXI libraries that can handle streaming data.
Maybe a stanza boundary needs to be included? So that a client can send complete XMPP stanzas to the parser. That would open up more options for developers and would result in quicker adoptions as soon as the first EXI libraries come out (which probably won't support streaming).
Regards, Jonathan Dickinson -- jonathan chayce dickinson ruby/c# developer email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] <some profound piece of wisdom>
smime.p7s
Description: S/MIME Cryptographic Signature
