The title pretty much says it all...

Is there interest in developing a collection of client/server protocol implementations (and a common "message" type) ? In particular, one that builds on top of Boost.Asio to implement the common protocol implementations that people usually require -- and then make it easy to create common types of server applications.

In particular, the goal of the project would be to:

o Come up with a common 'message' type which can be crafted as an object and passed around within/among the different networking functions/routines convertible to strings and constructible using a builder interface using Boost.Spirit

o Implement some common networking protocol clients like (but not

I believe it's this one: http://www.binarynotions.com/libhttp/ -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christian Henning Sent: Thursday, May 17, 2007 9:27 AM To: boost@lists.boost.org Subject: Re: [boost] Interest in a Boost.Network Library? Sounds very interesting. I think there is already a project doing http over asio. I cannot find the link anymore. Anybody? On 5/17/07, Dean Michael Berris <dmberris@friendster.com> wrote: limited to)

* HTTP * SMTP * SNMP

o Come up with base types or template classes which can be used to implement common server facitilies (via CRTP or PBCP) and modern C++ techniques (policies, TMP, etc.) to make the implementations flexible and extensible

The common message type is something I've already implemented in a different project (to be open sourced, but will serve a different purpose), which could be replicated or made generic. The semantic usage of the message type is shown below as an example/proposal:

using namespace boost::network; message m; int some_value = 100; m << header("some_header", some_value) << header("multi_value", tags::multi)(another_value)(some_other_value)(yet_another) << body("The quick brown fox jumps over the lazy dog");

std::cout << http::message(m) (url("http://www.boost.org")) (method(http::post)) << std::endl; std::cout << smtp::message(m) (to("boost@lists.boost.org")) << std::endl;

The above message type/object could then be used as the type commonly used by the HTTP/SMTP/SNMP protocol implementations.

If there's interest, I should be able to post code soon about it.

If there's already an on-going effort in this regard, I'd like to be able to contribute too.

If this is already done, then pardon the noise.

I can start a Sourceforge project for this, so if there are people interested in helping out I'd love to hear your ideas. Currently I've been developing it as a toy project on the side (pretty much the message type is thought out already and implemented in another project) and would like to know if people would like to use something like this and see something like it be made part of Boost.

Hope to hear from you soon!

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

http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Thanks guys, looking at the project's trac site http://trac.geekisp.com/libhttp/wiki and by browsing through the site it seems the project dried up for half a year. The last release was last year November and the source code on svn head seems equally old. Please correct me if wrong. Did anybody ever take a look on the design? Christian On 5/17/07, Darren Garvey <lists.drrngrvy@googlemail.com> wrote:

On 17/05/07, Christian Henning <chhenning@gmail.com> wrote:

...

Sounds very interesting. I think there is already a project doing http over asio. I cannot find the link anymore. Anybody?

I think this is the one you're talking about: http://www.binarynotions.com/libhttp/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I wouldn't mind helping out either. How about using Assembla http://www.assembla.com/home . It comes with svn, trac and of course it's free. Christian On 5/17/07, Jose <jmalv04@gmail.com> wrote:

Hi Dean,

I am interested. It seems there is no active project on this so please start a sourceforge project.

To get started I would focus on one protocol first, eg. HTTP, and make sure you get feedback from Chris and other heavy asio users (e.g. libtorrent author).

I am not sure your parenthesis syntax is the best. Do you have a rough design document ? (otherwise post a link to the code/sourceforge project)

I think this would eventually be a a great very useful addition to boost

thanks

On 5/17/07, Dean Michael Berris <dmberris@friendster.com> wrote:

...

The title pretty much says it all...

Is there interest in developing a collection of client/server protocol implementations (and a common "message" type) ? In particular, one that builds on top of Boost.Asio to implement the common protocol implementations that people usually require -- and then make it easy to create common types of server applications.

In particular, the goal of the project would be to:

o Come up with a common 'message' type which can be crafted as an object and passed around within/among the different networking functions/routines convertible to strings and constructible using a builder interface using Boost.Spirit

o Implement some common networking protocol clients like (but not limited to) * HTTP * SMTP * SNMP

o Come up with base types or template classes which can be used to implement common server facitilies (via CRTP or PBCP) and modern C++ techniques (policies, TMP, etc.) to make the implementations flexible and extensible

The common message type is something I've already implemented in a different project (to be open sourced, but will serve a different purpose), which could be replicated or made generic. The semantic usage of the message type is shown below as an example/proposal:

using namespace boost::network; message m; int some_value = 100; m << header("some_header", some_value) << header("multi_value", tags::multi)(another_value)(some_other_value)(yet_another) << body("The quick brown fox jumps over the lazy dog");

std::cout << http::message(m) (url("http://www.boost.org")) (method(http::post)) << std::endl; std::cout << smtp::message(m) (to("boost@lists.boost.org")) << std::endl;

The above message type/object could then be used as the type commonly used by the HTTP/SMTP/SNMP protocol implementations.

If there's interest, I should be able to post code soon about it.

If there's already an on-going effort in this regard, I'd like to be able to contribute too.

If this is already done, then pardon the noise.

I can start a Sourceforge project for this, so if there are people interested in helping out I'd love to hear your ideas. Currently I've been developing it as a toy project on the side (pretty much the message type is thought out already and implemented in another project) and would like to know if people would like to use something like this and see something like it be made part of Boost.

Hope to hear from you soon!

-- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 17/05/07, Christian Henning <chhenning@gmail.com> wrote:

I wouldn't mind helping out either. How about using Assembla http://www.assembla.com/home . It comes with svn, trac and of course it's free.

Christian

I'm interested in helping out too, this is something that would be useful to me. Kind regards, Glyn

Hi Dean, On 18/05/07, Dean Michael Berris <dmberris@friendster.com> wrote:

Those interested in being part of the project, please email me your sourceforge usernames so that I can add you up.

This project has come up at just the right time. There will certainly be some overlap between the proposed library and the library I'm working on for the GSoC (a CGI library). I've been trying very hard to imagine how the library can be structured so that HTTP and other protocols can in theory be incorporated later on. A networking and a CGI library are definitely distinct, but (IMHO) both could really benefit from being interoperable and reusing code. I'm trying to get my ideas down on paper at the moment; when they're done I'll put them on the boost wiki (http://svn.boost.org/trac/boost/wiki/soc/2007/cgi). If you (or any others) have suggestions to help interoperability or see any glaring flaws or crude assumptions I've made which hamper it, please tell me! :) Thanks, Darren

Hi Jose! On 5/17/07, Jose <jmalv04@gmail.com> wrote:

I am interested. It seems there is no active project on this so please start a sourceforge project.

Thanks! I'll do that tonight (my time) and hopefully in a couple of days the guys over at Sourceforge would be able to enable the project.

To get started I would focus on one protocol first, eg. HTTP, and make sure you get feedback from Chris and other heavy asio users (e.g. libtorrent author).

Starting with HTTP is definitely the intention. However, I think starting with the simplest and most flexible 'message' type would be time well-spent so that further development of the other protocol implementations can start using the common message type.

I am not sure your parenthesis syntax is the best. Do you have a rough design document ? (otherwise post a link to the code/sourceforge project)

Parenthesis syntax is something I tried imitating from the Boost.Program_Options and Boost.Assign (probably Boost.Assign will be used to implement this anyway) but if it doesn't convey the intended meaning I'm open to not using parentheses. :D I don't have a design document yet, but I certainly can come up with one in a Wiki somewhere. But I can sketch out the concepts in another post to the mailing list for comments. I'll work on that document today and formalize the design decisions and approaches to be taken to ensuring that the message type is as generic yet as usable as possible.

I think this would eventually be a a great very useful addition to boost

I hope so too. :)

thanks

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

Hi Stjepan! On 5/17/07, Stjepan Rajko <stipe@asu.edu> wrote:

I like this idea too - I've been dabbling with an RPC library and have tried to separate out the authentication part of the communication protocol. If I can use your library to make use of different authentication protocols to initiate connections between an RPC server and a client, I'd be happy to try it out and use the RPC library as a test bed.

Sounds good to me! Thanks for the interest! -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

On 5/17/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> wrote:

Dean Michael Berris wrote:

...

std::cout << http::message(m) (url("http://www.boost.org")) (method(http::post)) << std::endl; std::cout << smtp::message(m) (to("boost@lists.boost.org")) << std::endl;

Does that mean the message won't be able to be read incrementally?

In the above example, the overload to operator<< will turn the message into a string for output. It can definitely be made such that an adapter to make a http_message instance an InputStreamIterator will return chunks, but in essence a message is basically an object that keeps information. Making 'message' act like a multi-container would also help, something like: using namespace boost::network; message m; m << header("SOME_HEADER", 100) << header("OTHER_HEADER", 101); std::copy (begin<std::string>(headers(m)), end<std::string>(headers(m)), ostream_iterator<std::string>(std::cout, "\n")); The message type (and instances) will contain information that will later be used by routines relating to HTTP. For example: using namespace boost::network; message m; m << header("HOST", "www.boost.org"); http_request request(http_message(m).url("http://www.boost.org/")); copy (istream_iterator<std::string>(request), istream_iterator<std::string>(), ostream_iterator<std::string>(std::cout, "\n")); Should be doable, but is dependent on how 'http_request' is implemented. So there are two parts here: the message type being "convertible" to a string and it being "chunk-able", and the other part being the result of network operations given a message instance as the "driver" or "source" which forms the actual request. Things should be clearer when I come out with a design document. ;-) -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

Hi Andrey, On 5/17/07, Andrey Semashev <andysem@mail.ru> wrote:

Will the library be text-based protocols oriented or will it support binary protocols as well?

I should be able to but for the meantime, I would like to focus on text-based protocols first like HTTP, SMTP, and mybe something like XMPP -- if there's enough XML processing libraries available, or when we get a decent one into Boost. The idea is that it should be easy to implement client protocol handlers especially if it's going to be using the same message type that all the other implementations will be using. This allows for maximum flexibility and extensibility, so that we can work on adding more and more stuff into the library later -- or let users define their own non-standard special protocols with easy to reuse components. I hope this answers your question. -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459

Hi Alex! You can check out http://cpp-netlib.wiki.sourceforge.net/ -- we have some documentation there. We already also have a mailing list, and are discussing some pertinent issues which might be interesting to you as well. As for the structure, we're currently building upon a common message type -- and Peter Simons has already implemented an RFC2822 (?) parser, which I think will grow to include a lot more parsers for other RFC's. We're looking at moving network-protocol specific implementations in their own namespaces -- HTTP parsers are in something like network::http::parser for example. There are other things which need some more attention, and we're currently discussing them in the cpp-netlib developers mailing list. If you're interested in joining that discussion as well, you can hop on over to http://tinyurl.com/32tyzd (links to cpp-netlib-devel sourceforge mailing list archives) and subscribe to the mailing list. :) Thank you very much for the interest! (I should be able to add you to the project if you want to be part of the effort). :) -- Dean Michael Berris <dmberris@friendster.com> Mobile: +639287291459 YMID: mikhailberis