Re: [boost] Boost.HTTP ?

From: Andrey Tcherepanov (moyt63c02_at_[hidden])
Date: 2007-12-10 16:00:46

On Mon, 10 Dec 2007 13:28:42 -0700, Michael Dickey <mike_at_[hidden]>  
wrote:

[snip]
> There's two possible approaches to this that I see, one is to merge a
> "server" space into the Network library:
>
> boost::net::basic_message<>
> boost::net::http::request : public basic_message<>
> boost::net::http::response : public basic_message<>
> boost::net::server::tcp

> boost::net::server::http : public tcp

> Another would be to create an independent "server" library that uses
> the Network library classes:
>
> boost::server::tcp
> boost::server::http : public tcp
>
> They both seem like sensible approaches to me.  In either case, I
> think that HTTP would be a good starting focus for both, to get a
> working foundation incorporated into boost.  We could always submit
> additional protocols independently for review as their implementations
> are finished.
>
> What do you think?
[snip]

(assuming that "what you think was directed to all of us, not just Dean  
:), so below is my $0.02 CAD)

I like the idea of basic_message<> (which could be used for SMTP and gods  
know what else as well), but what about UDP servers or, generally  
speaking, multi-transport protocols?

Although http is sitting on top of TCP, there is an RTSP protocol which  
claims to be derived from HTTP/1.1 in most parts (well, at least RFC has  
lots of backrefs to HTTP spec), but allows to use connectionless transport  
(aka UDP). Moreover, RTSP treats Clients as something that can receive  
asynchronous stream change notifications (if allowed). I am not arguing  
that your design will not cover 95% of useful cases, but I think protocol  
parsing and transport layer might need more separation. This way if brave  
person will decide to implement RTSP (for example) as derived from HTTP,  
he/she will not be limited by TCP transport.

Thanks,
   Andrey