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

Re: [EXI] Partial flush

From: Daniel Peintner <daniel.peintner@gmail.com>
Date: Wed, 1 Oct 2008 20:11:59 +0200
Message-ID: <abbf52e10810011111k57a7c4aaxae424059da3b94f8@mail.gmail.com>
To: "Yuri Delendik" <yury_exi@yahoo.com>, public-exi@w3.org

Hi Yuri,

> By buffer I meant 1 byte (8 bits). Now there is no way for EXI encoder send incomplete byte to the underline channel.

Sorry for my initial misunderstanding.

> 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.

Now I see your problem.

A solution with EXI that could solve your problem may be the
byte-alignment option.
Byte-alignment generally results in EXI streams of larger sizes
compared with their bit-packed equivalents but byte-alignment provides
encoded data on aligned boundaries.

Please let us now whether this proposal is a possible solution for you.

Thanks,

-- Daniel




>
> 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 Wednesday, 1 October 2008 18:12:34 UTC

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