Re: [boost] Boost.HTTP ?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-12-11 00:31:21

Hi Andrey,

On Dec 11, 2007 5:00 AM, Andrey Tcherepanov <moyt63c02_at_[hidden]> wrote:
>
> 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?
>

basic_message<> is intended to be divorced from the actual transport
being used to put the contents of it out the wire. The idea of
basic_message is primarily as a common structure -- or the foundation
-- on which all operations lower level (network transport,
serialization/deserialization, etc.) and higher level (protocol
specific transformations, chaining, stream operations, etc.) will deal
with. If I only had the time and talent, I'll come up with a visual
representation as to how the basic_message<> fits in all this
network-related code with a simple layered design. For now, this is
how I envision it:

Adapters/Transformations Layer
----------------------------------------------------
| basic_message<> and derivatives |
----------------------------------------------------
Transport Layer

For a client protocol 'stack', there will be protocol specific
adapters and transformations higher than the basic_message<>
abstraction and protocol specific derivatives. So the idea would then
look like (for HTTP):

HTTP Transformations/Adaptations Layer
------------------------------------------------------------
| http_request / http_response
| both deriving from basic_message<>
------------------------------------------------------------
Generic/HTTP Transport Layer

Question might be, what the transformations/adaptations layer would
contain. There is no straight answer, but what comes to mind are the
following:

- Stream Adapters (create an HTTP Session "Stream", cookie support, ETags, etc.)
- Iterator Adapters (turn a message or set of message(s) into
iterator-accessible objects for STL friendliness; further examples can
be imagined if there was more time to do it)
- Protocol-Protocol transformations (example, HTTP<-->SMTP, or
HTTP<-->XMPP, etc.)

And the possibilities are endless. ;-)

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

It will be divorced -- the concept of messages have nothing to do with
the actual transport and processing that happens in a specific
protocol stack.

I hope this helps! :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]