From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2007-12-03 05:48:24
Scott Woods wrote:
> * a list of benefits/advantages of IOChain over existing io streams
> might be good?
>
True. I need a rationale section in the docs.
> * some common usage examples might be good? i.e. configuration
> and/or application-specific "document"
>
I'll see what I can do for the next preview release. Right now I was
happy to get a number of essential components working.
> * is it possible to have runtime-selectable links in the IO chain?
> e.g. user selection of the encoding to be used.
>
Yes. Some components directly support runtime selection of parameters
(like primitive serialization rules in the assembler_filter, or external
coding in the character coder), and you can always compose chains using
the erasure, at the cost of a bit of overhead (of course - runtime
choices always impose overhead). For example, the SWF format contains a
flag in the header for whether the whole file is gzip-compressed or not.
You could read that like this:
file_source rawswf(filename);
assembly<native_rules, file_source> header_reader(rawswf);
octet sig[3], version;
header_reader.read(to(sig));
if((sig[0] != 'F' && sig[0] != 'C') || sig[1] != 'W' || sig[2] != 'S') {
throw not_swf(); }
bool compressed = sig[0] == 'C';
header_reader.read(to(version));
if(unsupported(version)) { throw unsupported_swf(); }
if(version < 6 && compressed) { throw bad_swf(); }
uint32_t length;
header_reader.read(to(length));
source<iobyte> swfbody(compressed ?
chain(rawswf) | zlib() :
chain(rawswf));
Now you can just continue reading from swfbody. The compression is
transparent. (Aside from the loss of the seeking capability.)
Sebastian