Dear Peter,
(2013/03/13 23:10), Peter Waher wrote:
Anybody interested in EXI & XMPP, please review. Any feedback is most welcome.
I think this idea of schema exchange is interesting. On the other hand,
it may make confusion on management (explosion of the number of derived
schemas). If there is a way to name a XML schema defined in XEP, servers
and clients can share them by the names. Of course (1) this does not
eliminate needs to upload XML schema because the end device may have
non-XEP vendor specific extensions (2) we need secure channel to
download XEP-defined schemas to avoid attacks.
Another pitfall: if we want to use bit-packed, we need to make stanzas
encoded as self contained elements. Otherwise you cannot do 'fflush()'
at the end of element of a stanza. However, self contained elements do
not allow an encoder to re-use compression context (string tables)
between outside of the element and the element itself. This means the
encoder need to re-encode JID strings as is (otherwise you can just
encode a string with few bytes of reference). This may make the XMPP/EXI
stream more inefficient compared to byte-aligned streams. My preliminary
experiment shows following results.
[The number of bytes]
bytes
-----------------------------+-------
XML | 3681
selfContained, bit-packed | 1589
byte-aligned | 1358
-----------------------------+-------
Note: the results do not use schema-informed grammars to encode
XEP-based elements, so compression ratio of Peter's proposal should be
much better -- in my best scenario with schema-informed EXI, it will be
809 bytes (22% of original XML).
BTW, my initial idea is somewhat different. What I want to make is
constrained XMPP clients (and if technically possible, servers) with
static set of pre-compiled EXI grammars and without ability to talk with
regular XML-based XMPP. This enables nodes with batteries to speak
sensor data with narrow wireless link such as 15.4 or with 3G link
charged by quantity. Maybe this idea is oriented towards SRV-based
negotiation.
For long-targetted apporach, I think I can propose some update to EXI
spec itself (I recently joined to W3C EXI working group). Now EXI
working group are open to collect requirements for EXI2.0 (I already
raised fflush() issue). I believe this kind of collaboration should be
very important to let more constrained IoT devices join the network.
Regards,
Yusuke
