This document:Public document·View comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group Other specs in this tool
Quick access to LC-2103 LC-2104 LC-2105 LC-2106 LC-2107 LC-2108 LC-2109 LC-2110 LC-2130 LC-2132 LC-2133 LC-2164 LC-2165 LC-2166 LC-2167 LC-2168 LC-2169 LC-2170 LC-2171 LC-2172 LC-2173 LC-2174 LC-2175 LC-2176 LC-2177 LC-2178 LC-2179 LC-2180 LC-2181 LC-2182 LC-2183 LC-2184 LC-2185 LC-2186 LC-2187 LC-2188 LC-2189 LC-2190 LC-2191 LC-2192 LC-2193 LC-2194 LC-2196 LC-2197 LC-2198 LC-2227 LC-2248
Previous: LC-2189 Next: LC-2172
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