[LC-2192] RE: [EXI] Partial flush

Hi Jochen,

The blocksize of EXI compression is constant for a single EXI stream so that
an EXI decoder get an approximate idea of how much memory is necessary for
buffering events before it starts decompression. One of the inclinations of
EXI design was enabling those devices with limited hardware resources, often
with very limited network resources to successfully tap into XML family of
technologies.

For the scenario you described, the best solution may be to feed a flow of
separate EXI documents or EXI fragments, each of which has been compressed
independently.

The other thing that may be relevant and worth mentioning is that EXI
compression is designed to cost much less CPU cycle than gzip does, yet
consistently with better results.

This trait is known to enable certain scenarios to apply EXI compression for
their output feeds, wherein application of gzip has been perceived prohibitive
given the exhaustion of server CPU resources due to the high processing cost
entailed in compression.

Hope it helps,

-taki


-----Original Message-----
From: public-exi-comments-request@w3.org [mailto:public-exi-comments-request@w3.org] On Behalf Of Jochen Darley
Sent: Friday, November 07, 2008 2:27 AM
To: public-exi-comments@w3.org
Subject: Re: [EXI] Partial flush

Hello Taki Kamiya,

Thanks for the response.

Taki Kamiya schrieb:
> EXI provides a facility called "self-contained elements" that can be
> leveraged to enable such functions like indexing, skipping, etc.

> To use self-contained elements, an option in the header "selfContained"
> needs to be turned on. It is worth noting that this option is mutually
> exclusive with "compression" option. Self-contained elements can be
> used only in non-compression mode.

The self-contained elements will not work for my scenario (if I'm
restricted to non-compression mode). In that scenario skipping is only a
bonus.

My scenario pre-compresses multiple XML fragments and then combines
these into multiple EXI streams/documents.
AFAIK: This scenario is prevented by the same constraints which prevent
"skipping" in compressed mode.

I'll explain the scenario in more detail along with some questions in
the next email (subject: Precompressed EXI Fragments).

Regards
Jochen Darley

Received on Wednesday, 7 January 2009 19:46:37 UTC