(2013/03/20 5:47), Peter Waher wrote:
Dear Yusuke
Thanks for your mail. Regarding your questions and comments:
Ok, so I think I need to write another proposal. Would you mind if
I re-use the basic idea on 'EXI encoding part' of your proposal to
make better interoperability?
By all means. It would be excellent if you did. It would allow
devices to be able to connect freely between servers supporting
either of the two versions.
Thanks :-)
The proposal supports different EXI versions. It's part of the
negotiation, using the version attribute.
I see, then may I assume you have no intention to make 'yet another
EXI for XMPP' such as sessionWideBuffer option?
I'm not sure what you mean with 'yet another EXI for XMPP'. Where do
you find another proposal for EXI with option negotiation?
Also, we plan to let the sessionWideBuffer to stand for the time
being. I believe it's an important aspect of the integration of EXI
into XMPP. And as I showed using my examples (which are in no ways
extreme, they are in fact two common use cases in sensor networks)
sometimes one option is better than the other. One option is not the
best for all use cases.
I would say 'yet another EXI for XMPP' for EXI streams not be able to be
decoded by current EXI-1.0 compatible implementations, such as EXIP,
OpenEXI, and EXIficient. Your proposal seems to expect somewhat
different handling in EXI stream structure, including sessionWideBuffer.
I agree re-use of string table is important in terms encoding
efficiency. However, how to make it needs careful consideration.
Inter-stream session management could be a good idea worth standardized
in future version of EXI (however, this may involve out-of-EXI session
negotiation such as something like EXI-cookie option to find identical
session state). If you have long term point of view, it's better for
XMPP folks and EXI folks to make some discussion to solve.
(BTW, my proposal to handle this is to add NOP rule to let an element be
pushed out even in bit-packed stream)
On the other hand, if you need something you can use NOW, I believe you
need to stay in compatible stream structure. (You may think differently,
this is just my opinion).
Added a note in ยง2.7. regarding this, since it was unclear. <stream>
is only written at the start of a stream, and </stream> when the
stream is closed, with stanzas inbetween. When entering
EXI-compressed mode, the <stream> and </stream> should be omitted.
I'm not quite sure ... You mean something like this?
<stream>
<compress>...</compress>
</stream>
<!-- from here EXI stream starts -->
SD
SE("iq")
... (contents of iq)
EE
ED
(fflush(), PSH)
SD
SE("message")
... (contents of message)
EE
ED
(fflush(), PSH)
Regards,
// Yusuke DOI <[email protected]>
