Re: [boost] [rfc] I/O Library Design

From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-27 17:36:42

----- Original Message ----- 
From: "Jeremy Maitin-Shepard" <jbms_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, June 28, 2007 8:21 AM
Subject: Re: [boost] [rfc] I/O Library Design

> "Scott Woods" <scottw_at_[hidden]> 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