W3C home > Mailing lists > Public > public-exi@w3.org > March 2013

RE: [Standards] Proposal for including EXI in XMPP

From: Peter Waher <Peter.Waher@clayster.com>
Date: Fri, 15 Mar 2013 18:09:45 +0000
To: XMPP Standards <standards@xmpp.org>
CC: "public-exi@w3.org" <public-exi@w3.org>, Randy Turner <rturner@amalfisystems.com>
Message-ID: <1693EFE1FD641C42A0D542FCBC732DE698E53F3C@EX3.YODA.UTOPIA.LOCAL>
Dear Randy

Constrained here, apart from the normal English definition, could mean any reason why they would not otherwise be able to use XMPP as a transport protocol.

One constraint could be allowable packet size. Wireless sensor networks (for example over 6LowPan) can only send small packets. So, it might well be that compressing the stanzas would enable them to send control messages vs. not being able to send them (successfully). Partitioning small messages into several parts in otherwise congested WSN might not be a practical option.

Another constraint may be available RAM for buffers. While they may actually have plenty of ROM to store code, schema files, etc., RAM might be limited.

Furthermore, efficient code can be automatically generated from schema files, so writing and reading EXI can be surprisingly efficient (both in size and processing power), if strict schema compression is used.

Sincerely,
Peter Waher


-----Original Message-----
From: Randy Turner [mailto:rturner@amalfisystems.com] 
Sent: den 15 mars 2013 12:08
To: XMPP Standards
Cc: public-exi@w3.org
Subject: Re: [Standards] Proposal for including EXI in XMPP


I was curious what the definition of "constrained" is ?  

EXI does produce a compact representation of XML (which is good if "constrained" is meant to apply to the amount of any output XML representation)

But I think the executable code size of an EXI implementation might not be appropriate for a "light switch", "low-power sensor"  or other similarly constrained memory device.

But I guess it depends on the definition of "constrained" memory?  (both RAM and non-volatile code space) -- especially since there may be a dual-stack IPv4/IPv6 stack, HTTP module, operating system, and other code already assumed to be on the constrained device.

Randy


On Mar 15, 2013, at 3:39 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 3/14/13 6:50 PM, John Schneider wrote:
>> Peter,
>> 
>> Its really great to see some momentum on this! Thanks very much for 
>> the energy you are putting into it. This is something in which I've 
>> had a long-running interest. In fact, I think Peter and I first 
>> talked about it back in 2005 (yikes!). Although I'm not sure Peter 
>> was completely sold on the idea at the time (broccoli ice cream 
>> anyone? [1]), he was gracious enough to help us get the XMPP EXI use 
>> case together [2] and even started an early draft [3]. Thanks Peter! 
>> ;-)
> 
> One must keep an open mind.
> 
>> Here at work, we have incorporated EXI into various XMPP solutions to 
>> support our Efficient XML users (e.g., to enable XMPP on aircraft). 
>> So, I'm very interested in following your progress.
>> Please keep me in the loop as you move forward. I'd be very happy to 
>> help if I can.
> 
> Yesterday at IETF 86 I had a productive chat with Yusuke Doi on this 
> topic. He helped me see that, just as we've defined HTTP bindings 
> (BOSH / WebSocket) for web endpoints like browsers, an EXI binding 
> would expand the universe of XMPP usage to constrained devices of the 
> kind that might otherwise use protocols like CoAP.
> 
> Although I've not yet had time to read the new EXI proposal in detail, 
> I shall do so as soon as possible and provide comments on the 
> standards@xmpp.org list.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRQvpOAAoJEOoGpJErxa2pcfMQAKPeGWf+02AZmrGff3hA+H+I
> g9INO8/62pukrj7utK1BuBRkersMXLxJUm3TIWnfQuqBXe/zgbkcvms42GHvu9+R
> J5/37i4Mq+lKHdI/XyPtLnn6/3YjriotGwl2ZKpvxvD4b66F0BL0jUaCoZx6jpPm
> N7QNYtX51uzpU7ofWfWf/IhzXOKNgFaB4u/EVcJp4+Gu8UInnualtkeq/ZHQwEiG
> SkpE36LfuCy31cXEd4Oankv30ywOwUmh2ETwzLyeDPzPfhFVdjgNkabnJr1J/H/n
> 8GnZNIEgzx/hFTGUetHkhMaHQfqGAVtEjWsFIYStugQnBRS6pP/V+fEME4DEMw64
> FLf9sF8sJBSP4/e62Z8myog/eVWrYiGNjGRu8qvo+fNmD4Fn+/qhHA/SvYcN+ZXN
> yqeqzAJty+A+oxduPCN+bbP93grroSjs1qmN7ybsu+bO9hJiDCs3IIsJPOBZrr9Y
> uQ+an33QWIAEsPRO4VKQlFYxHmh6QRjUPTCeFyFemuD7dyLk3UBXNikMUrvcFwBa
> uj0jAyC0tIf0w/Qm5RPtzVIV02On1jKRjHGoNLjEnjf0nusmdqzEZMq3mIL95PzL
> g1WYu5ASmDVAzWUuwvhYYMGraAQbqrnj5+QgiaAEHulpjl43ut7FHYslD7uyPvFp
> E8efql+LqrpSRCjgvZ8e
> =jNUK
> -----END PGP SIGNATURE-----
> 
Received on Friday, 15 March 2013 18:10:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:44 UTC