- From: Daniel Peintner <daniel.peintner@gmail.com>
- Date: Thu, 25 Sep 2008 16:54:22 +0200
- To: "Yuri Delendik" <yury_exi@yahoo.com>
- Cc: public-exi@w3.org
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 14:55:01 UTC