----- Original Message ----- From: "Jeremy Maitin-Shepard" <jbms@cmu.edu> To: <boost@lists.boost.org> Sent: Thursday, June 28, 2007 8:21 AM Subject: Re: [boost] [rfc] I/O Library Design
"Scott Woods" <scottw@qbik.com> writes:
[snip]
I'll take that as a no :-) Maybe my concepts could do with a bit more work.
The detail on unicoding has been great. Thanks.
Perhaps you can elaborate on how your ideas about a conceptual framework for interpreting a byte stream as more structured data should affect the interface/design of the I/O library.
Yes. Apologies for loss of context :-) The short version; 1. Drop "Compression Filter and Misc. Filter" from "Binary Transport Layer" 2. Rename "Buffer Filter" as just "Buffering" 3. Bundle "Endianness" and "Representation" and call it "Network/Host Representation" 4. Pull the resulting "Network/Host Representation" out of the presented layering 5. Define other representations such as "ASCII Line", "UTF-8 XML" and "Command Line User" 6. Allow for representations to be composable, e.g, Command Line User<input = keys to basic C++ types,output = basic types to UTF 8> Usage might look like; file_device d; d.open( "file name" ); command_line_user<keys_to_basic,basic_to_UTF_8> cli; cli.attach( d ); while( cli.parse() ) { process( cli.interpreted_item ); } and; TCP_device d; d.open( socket_descriptor ); network_host nh; nh.attach( d ); while( nh.parse() ) { process( nh.interpreted_item ); } 7. Issue of sync and async is ancillary, i.e. dont believe anything in the above implies exlusive use in a sync or async environment. Justification for this claim is based on the "composable representation" objects holding all the parsing/formatting state internally. Regards, Scott