W3C

Edit comment LC-2192 for Efficient Extensible Interchange Working Group

Quick access to

Previous: LC-2189 Next: LC-2172

Comment LC-2192
:
Commenter: Jochen Darley <joda@upb.de>

or
Resolution status:

Hallo EXI WG,

I'll just start with an example scenario:

Let's assume www.markmail.org wants use an XML compression for their
services. Markmail offers personalized feeds of news and mailing lists
to it's customers (as RSS/Atom feed). The goal is to allow customers to
receive their personalized feed as a compressed XML stream.

If markmail implemented the compressed streams by compressing each
personalized stream by itself then they need a lot resources. My
assumption is that they will have to use a separate EXI compressor for
each (of the thousand) compressed customer streams.

The solution would be to pre-compress the feed's entries and just copy
them into the customized streams. Markmail can't use a single continuous
EXI stream because:

1) EXI has a global string table which can't be reset per block
2) EXI enforces a fixed blocksize "n" except for the last block

My solution would be to pre-compress multiple XML fragments and then
copy compressed fragments into the customers personalized stream.

My questions:

1) How will EXI support such a compressed, streaming
scenario?

2) Should EXI support this scenario ?

3) What are the design intentions for the fixed blocksize?

4) Is it acceptable to remove the fixed blocksize?

5) Can a mode be added to EXI which resets the string table
for each block?

6) What are design choices/constraints which require a global
string table or the fixed blocksize?

Regards,
Jochen Darley
(space separated ids)
(Please make sure the resolution is adapted for public consumption)


Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: 2192.html,v 1.1 2017/08/11 06:44:22 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org