Re: [cpp-netlib-devel] Insights to the Message Class and Network Routines

[Alex O. <al...@gm...>]

Hello all

On 23 May 2007 19:42:26 +0200, Peter Simons <si...@cr...> wrote:
> Hi Dean,
>
> it feels like we have different perspectives on the subject of
> networking. I mostly care about the server side. You seem to have
> more experience with the client side. Consequently, our views
> disagree on several occasions. This is good thing, because by
> finding a solution that we can agree on, we will come up with a
> solution that is better than any one either of us could have come
> up with alone.
>
> The difficult bit is to handle disagreements constructively.
>
> After thinking some ideas through, I feel that I might have been
> aiming too high. An HTTP implementation is beyond our scope. I
> see it like this: when I want to write a sophisticated web
> application, I don't bother with an HTTP server. I write a CGI or
> FastCGI that works with _any_ HTTP server. Even assuming that I
> would have to commit to one particular HTTP server, frankly, I'd
> probably write an Apache module instead of a policy-driven
> handler functor for Boost.Network.
>
> I wonder what our users hope to find in this library when it's
> finished. Please, everyone feel encouraged to post a list of
> things you would personally like to have; things you miss when
> writing network-oriented C++ code. Here is what I'd like to have:
>
>  (1) A class to represent any kind of URI. I want to be able to
>      read an URI by saying "Uri uri; cin >> uri;", and there it
>      is. I would also like to be able to write open(uri) to
>      obtain a stream socket that is connected to the address the
>      URI represents. (libcurl does something like this in C.)
>
>  (2) Uri's know "mail:user@domain", so clearly (1) requires a
>      class to represent an e-mail address. I frequently need
>      lists of addresses too.

I'm not sure, that mailto: should be treated as an uri at SMTP messages

>  (3) Parsers for all kinds of HTTP and E-Mail headers. I have
>      "Date: Wed May 23 19:05:46 CEST 2007\r\n", and now I want to
>      know what time that is. The same goes for
>      "If-Modified-Since:" and a lot of other headers.
>
>  (4) A class to represent multi-part MIME messages. MIME is used
>      in e-mail and in HTTP, yet in practice it's notoriously hard
>      to handle. A good MIME Message class should support
>      registering content-type-specific data handlers. Issuing a
>      GPG certificates -- or verifying one -- is something such
>      user-supplied function could do.

Yes, MIME support is important for all of protocols in current time.

In our parsers, that we implemented on my previous work  (currently
closed source) we had presented the message as a "lazy" structure,
that parse data when we try to access to underlying elements (usually
by name).
So for example, HTTP request consists from:
Method URL Version
Headers
empty line
Body

every of elements had parsers, associated with them, and it was
possible to change parsers at runtime (especially for POST's).  For
headers, also was a list of mappings Name -> parser, that allow us to
transparently parse data in headers, and represent them as a string or
corresponding structure (members of that, also was available via named
map).
And when members of structure was changed, the text representation
also will rebuild, when requested

Here small example:

node_type uri("uri", request["uri"].value(), new
mimer::http::uri_nparser<std::string>);
cout << "query=" << uri["query"].value() << std::endl;
// .... process data ...
request["uri"]=newUri; // modify it

-- 
With best wishes,                    Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/