----- Original Message ----- From: "Sebastian Redl" <sebastian.redl@getdesigned.at> To: <boost@lists.boost.org> 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