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

[Peter S. <si...@cr...>]

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.

 (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.

If Boost.Network offers high-quality solutions for those
problems, I'll be a user. I also feel that getting those classes
implemented and documented up to the standards Boost expects will
be a major effort that's measured in months, not weeks.

Anyway, we have also talked about DNS:

 > Remember though that Chris already has a resolver in
 > Boost.Asio...

Well, Asio has a wrapper for getnameinfo(). That is a portable
system call that gives synchronous access to the resolver the OS
uses. The system resolver is very convenient and great to have,
but it is a synchronous resolver. A great many applications can't
use it. Furthermore, the system resolver knows only about A
records and PTR records. You can resolve names to addresses or
addresses to names, but you cannot look up a mail exchanger or a
TXT record. For all but the simplest applications, the system
resolver is insufficient.

I feel an asynchronous DNS resolver is beyond the scope of Asio
or Boost.Network. Providing convenient and type-safe access to
the asynchronous resolvers other people have written, however,
might be worthwhile.

Take care,
Peter