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