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

Re: [EXI] Partial flush

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
Message-ID: <185000.78102.qm@web83201.mail.mud.yahoo.com>

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

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