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

[Dean M. B. <mik...@gm...>]

Hi Peter!

On 23 May 2007 19:42:26 +0200, Peter Simons <si...@cr...> wrote:
>
> 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.
>

I agree. When I proposed this networking library, I was more concerned
about implementing common client protocols, and have been pretty hazy
(or not very dedicated) to writing implementations for the server
side.

Your insights have opened my eyes to some issues I've failed to
consider on the server side implementation details, and now I'm doing
a lot of re-thinking about what the most productive approach would be.

> The difficult bit is to handle disagreements constructively.
>

Indeed. I however, am very open to suggestions and comments, so please
keep them coming. I certainly appreciate the input at any level. :-)

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

On the server side, I agree that it might be too ambitious to
implement the HTTP protocol and provide a "hook-into-skeleton"
implementation. But I'm not afraid to try and fail in this regard. :-)

So we can definitely forgo the server side HTTP implementation. While
I do agree that it would make sense to just write an application that
talked FastCGI or whatnot instead of using a http::server<...>, in my
work at Friendster I've seen that this does not scale well for
thousands of connections at a time.

I however am looking more at a very flexible HTTP client library. One
which any C++ programmer with STL experience will be able to use right
off the bat with minimal mental cartwheels.

> 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:
>
[snipped great list]

I'd like to add the following to that:

o  A set of primitive networking routines like a "blocking read that
times out" or a "self-reconnecting socket connection" and "a raw
packet builder/sender".

o  A minimal but comprehensive HTTP client implementation

o  A minimal but comprehensive SMTP client implementation

o  A flexible interface/framework where I can add more protocol
implementations easily, or with very little effort (example, I want to
implement a new binary protocol, I just need to add a few classes
which talk a certain "language" and then leverage on whatever
Boost.Network already has)

So indeed, a URI class and a MIME handler would be good to have. I'm
still not sure though how we could make that work without dynamic
runtime programming (virtual, all that inefficient stuff).

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

Yes, but I am positive we can get a minimal HTTP/SMTP client going in
a couple weeks time. ;-) So the sooner I'm able to commit some more
stuff sitting on my machine, the better it would look as the days go
by. :-)

If anybody also has stuff you'd like to put into the subversion,
please feel free to do so. The sooner we can evaluate code from other
people, the faster this process could go. :-) (Take this as a call for
help, and if you can pick up from where the code currently already
is).

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

Ah, okay. Then that would be a good thing to implement, if the DNS
client that works on most platforms is inadequate, having one in
Boost.Network would make sense. Unless there are already better
implementations that do the job already...

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

I think implementing a server would be out of bounds of the
Boost.Network scope, but a header-only client can be very attractive.
:-)

> Take care,
> Peter
>

Thanks very much Peter for the insights! :-) They definitely help. :-)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459