----- Original Message ----- From: "John Hayes" <john.martin.hayes@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, June 26, 2007 9:38 AM Subject: Re: [boost] [rfc] I/O Library Design
I don't think any of the transformation are accurately represented as encoding a byte stream as text. I'll quickly address base-64 because it's different from the others; this is a bitstream representation that happens to tolerate being interpretted as character data in most scenarios (base-32 also tolerates case conversion - so it's suitable for HTTP headers).
Sorry but not responding to your mail specifically but all of the recent postings on this topic. This material has been excellent for me. It has expanded the problem but strangely brought some clarity. Maybe ;-) There seems to be, as always, a suite of requirements hiding under a single title. This started out as "I/O library" and is now addressing the proper handling of mail attachments. Wonderful stuff but if these different requirements arent acknowledged it will be easy to bounce from one to the other. What about this; 1. There is an interaction with a device. This involves opening and closing with zero or more block I/O operations in between. 2. A byte-stream facillity may be associated with one of these device sessions. 3. The byte-streams may be interpreted an infinite number of ways. Some example interpretations (that happen to match common uses) appear below. This set of uses in no way precludes other useful interpretations from emerging. a) A series of variable length, free-format messages (i.e. lines) b) A single item of structured data (XML) c) A series of variable length messages with embedded data (i.e. lines carrying instances of formal data notations) d) .... (representing the infinity of other uses) 4. Very generally these use cases derive different structure from the stream. Whether this is as simple as a series of messages separated by newlines or the extensive structure and info in a SOAP message, the activity is abstractly equivalent. 5. At each level of structure the interpreter is free to enforce further rules, e.g. the two level stream of lines might require that the content of each line is in UTF-8 while the arbitrary-level stream (XML) requires that all document content is in UCS-2 and everything else is ASCII (possibly confusing example). A need for the latter example might arise where the interpretation input is only ever viewed by developers and support staff (all speaking English) while the stored content is being viewed and modified at many sites around Europe. There is a lot more that I can inject into this thread but before I make a tit of myself, is this making sense to anyone else? Scott.