On Mon, 10 Dec 2007 13:28:42 -0700, Michael Dickey <mike@mikedickey.com> 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