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
>> The document can be found here:
>> 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. :-))
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
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.
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
processing terms "simple accepting states"
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
* 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)
illuminating (Unicode). For me there are bytes (or basic units) and items
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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk