- From: Yuri Delendik <yury_exi@yahoo.com>
- Date: Thu, 25 Sep 2008 11:18:29 -0700 (PDT)
- To: Daniel Peintner <daniel.peintner@gmail.com>, public-exi@w3.org
Hi Daniel, By buffer I meant 1 byte (8 bits). Now there is no way for EXI encoder send incomplete byte to the underline channel. Let’s use XMPP example. XML stream data will be send in following manner without closing the underline channel: XML, {time delay}, XML, {time delay}, …, XML. For example: <stream> {some time delay} <stanza1>…</stanza1> {some time delay} <stanza2>…</stanza2> <stanza1>…</stanza1> {some time delay} …. </stream> And EXI encoder may hold bits after <stream> or </stanza1> and not send them to the channel, but other party is expecting that data as soon as possible -- those stanzas can be time critical material. ZLIB has partial flush functionality that aligns bits to byte border and sends compressed data to the channel, and makes it available to other party. But it does not terminate compression process. Compression’s blockSize will not help is this case ether. Thank you. ----- Original Message ---- From: Daniel Peintner <daniel.peintner@gmail.com> To: Yuri Delendik <yury_exi@yahoo.com> Cc: public-exi@w3.org Sent: Thursday, September 25, 2008 9:54:22 AM Subject: Re: [EXI] Partial flush Hi Yuri, > Some XML streaming protocols such as XMPP require data to be delivered as soon as possible. > When bit-packed option is selected, an EXI encoder may keep some data in its buffer for long > time before sending to it the channel. There is no reason to buffer data when EXI uses the bit-packed alignment option. EXI events and values can be streamed directly. > XMPP solves similar problem for ZLIB via partial data flush (http://www.xmpp.org/extensions > /xep-0138.html#impl). It will be nice to have a "flush" event that will align the stream to byte > border like self-contained (SC) event does. Same event may also restart compression, when a > compression option is selected. When EXI runs with either the compression or pre-compression alignment option turned on some kind of buffering is necessary. EXI re-orders data in a way that compression algorithms achieve higher compression ratios (see [1], Blocks and Channels). To allow devices with limited memory process large documents the blockSize option [2] is configurable. The blockSize value restricts the number of Attribute (AT) and Character (CH) values per block. Hope this answers your question, Regards, -- Daniel [1] http://www.w3.org/TR/exi/#compression [2] http://www.w3.org/TR/exi/#key-blockSizeOption > Thanks > >
Received on Thursday, 25 September 2008 18:19:09 UTC