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

From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2007-06-29 12:36:28

"Scott Woods" <scottw_at_[hidden]> writes:

> ----- 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"

I'm not sure what you mean by this.  At what level would compression
filters operate?

> 2. Rename "Buffer Filter" as just "Buffering"
> 3. Bundle "Endianness" and "Representation" and call it "Network/Host 
> Representation"

I realize that some existing interfaces/specifications may refer to
endian conversion as network to/from host byte-order conversion, but
endian conversion can of course be used for things unrelated to network
protocols.

> 4. Pull the resulting "Network/Host Representation" out of the presented 
> layering

What does it mean to do this?  From your comments, it seems like you
might be saying that the stream abstraction is not particularly
important, and that some other abstractions should be of primary
interest.  Perhaps you can explain the alternate abstractions, though,
if this is the case.

> 5. Define other representations such as "ASCII Line", "UTF-8 XML" and 
> "Command Line User"

I don't quite understand what is meant by "command line user".  As far
as XML, it seems that aside from providing basic encoding conversion
facilities, the I/O library need not know anything about XML.

> 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 );
>     }

It isn't clear to me exactly what these code-snippets might be intended
to do.  Perhaps you can explain.

> 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.

It still seems that to support asynchronous operations, support would be
needed at every level of the library, but I am thinking primarily about
a stream abstraction.  Perhaps you can elaborate on this "composable
representation" abstraction idea, and how it might make supporting
both synchronous and asynchronous operations simpler.

-- 
Jeremy Maitin-Shepard