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

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2007-06-28 20:01:09

> ----- Original Message ----- 
> From: "Sebastian Redl" <sebastian.redl_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, June 18, 2007 3:51 AM
> Subject: [boost] [rfc] I/O Library Design
>
> [snip]
>
>> The document can be found here:
>> http://windmuehlgasse.getdesigned.at/newio/
>>
>> I'd especially like input on the unresolved issues, but all comments are
>> welcome, even if you tell me that what I'm doing is completely pointless
>> and misguided. (At least I'd know not to waste my time with refining and
>> implementing the design. :-))
>>

Hi Sebastien,

Thanks for the read of your doc. On the basis of that and the quality of the
related postings I think your efforts have already paid off.

 I made a couple of attempts to write a decent analysis of your design but
 they quickly became too detailed and not suitable for this mailing list. I
 suspect
 that my point of view also needs more work.

 Some of your open issues;
 * Basic Unit
 Small but ugly issue. My feelings are that non-8-bit-byte archictures need
 to be explicitly chopped out of the scope or a pure abstract "basic unit" 
(basun? like beson
 only more elusive :-) needs to be defined in a similar manner to a 
codepoint name. Its
 a strategic decision.
 Personally I would go for the 8-bit-only.
 * Async Requests
 All I/O is more cleanly considered to be async. A sync model of access can
 always be  implemented over the top.
 * Putback
 Very contentious. Currently I am swinging towards "no". I have a rule for
 all of my  encodings that each item has "positive termination" or in 
language
 processing terms "simple accepting states"
 * Representation/Endian
 I think this issue should be bundled with "parsing". Exactly what the ntohl
 functions do  is a nice simple model for what should be done here.
 * Inexact bit counts
 Refer to "Basic Unit".
 * Buffer types and encodings
 Buffers typed to encodings? No. The only thing buffered will be blocks of
 basic units.
 * Interface (I/O streams-like needed?)
 Yes, if only because adding the backward compatibility should be easy given
 the design/impl goes well.

 Some general points;

 1. Confusion around char, byte, text, binary, encoding and codepoint
 For me this has been a bit frustrating (its been untidy for a long time) 
and
 also
 illuminating (Unicode). For me there are bytes (or basic units) and items 
of
 application data. Everything in between is encoding.
 2. Inclusion of "endianness" and "representation" in the binary layers.
 IIUC you are allowing applications to declare that they will only talk to
 (e.g. ) Motorola-based machines. I suppose this can be justified but from 
an
 engineering point of view the strategy implicit in ntohl is more appealing.
 The subtle drawback of allowing the declaration of endianness and the
 fact that underlying operations (e.g. network nagling) shaft it anyhow
 makes it a "no go" for me.
 3. Lack of extensibility
 While your design doesnt actually preclude this, it also isnt explicit 
about
 it being possible, i.e. how would you redo your diagram for an application
 that is using different encodings over different network connections and to
 data files.

 Cheers,
Scott