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

From: Scott Woods (scottw_at_[hidden])
Date: 2007-06-25 22:57:33

----- Original Message ----- 
From: "John Hayes" <john.martin.hayes_at_[hidden]>
To: <boost_at_[hidden]>
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.