- From: Jochen Darley <joda@upb.de>
- Date: Fri, 07 Nov 2008 11:54:14 +0100
- To: public-exi-comments@w3.org
- Message-ID: <49141E56.3080108@upb.de>
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
Received on Friday, 7 November 2008 10:57:43 UTC