Hi Peter,
(2013-03-21 07:18), Peter Waher wrote:
* Some concerns have been raised that this proposal has slight
variations from regular EXI:
I would not say so. The compression/decompression part is the same. EXI options
are the same, except a few that have been removed since they do not work well
together with XMPP. Also, an XMPP-specific (relating to how the XMPP server
should use the EXI compression/decompression engine) option has been added
(which the server can reject if it wants to).
Maybe this is my comment (sent: Thu, 21 Mar 2013 01:11:49 +0900).I need to
clarify two points before I agree on this point.
1) streamWideBuffer (I think we share the problem, I don't restate it here).
2) stream structure (see below)
(copied from the previous mail)
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)
(/copied)
This is not an EXI stream, this is a set of EXI streams on the same TCP session (I'm
not opposing on it, it's a good idea). However, this structure changes overall
document structure: no <stream> tag on EXI part. XML equivalent is:
[from here EXI stream starts]
<iq> ... </iq> <!-- this is a document (or document fragment) -->
<message> ... </message> <!-- this, too -->
[End of TCP session]
I'm not the person who can say it's good or not good (I'm not XMPP spec geek,
yet).
Yusuke
