W3C home > Mailing lists > Public > public-exi@w3.org > September 2008

Re: [EXI] Partial flush

From: Daniel Peintner <daniel.peintner@gmail.com>
Date: Thu, 25 Sep 2008 16:54:22 +0200
Message-ID: <abbf52e10809250754w5af9f32ew4a75c2b236707f3d@mail.gmail.com>
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

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