cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Sourceforge tracker

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

Sorry for taking a while. Let me share my views below:

On Dec 11, 2007 9:46 PM, Glyn Matthews <gly...@gm...> wrote:
> Dear group,
>
>
> I've added a category and group to the feature tracker following on from the
> discussion about the HTTPParser from Pion.  Furthermore, I also added a task
> (HTTP integration).
>

Thanks Glyn!

> I'd like to know your opinions on how to best organise the SVN repository,
> tracker and task manager.  Currently, my thoughts are:
>
> A task corresponds to a separate branch in SVN (e.g. HTTP integration,
> version 1.0 etc.).  Feature requests are assigned to a group which
> corresponds to a task.  A feature request can also belong to a category
> which might be more descriptive ( e.g. documentation, security ...)
>
> Is there anything else?  If anyone wants to start working on something,
> create a task and an SVN branch and use this (I don't have access to the SVN
> repository here, so if someone wants to create a branch for the HTTP
> integration, please go ahead).  If you want me to add more categories and
> tasks, let me know.
>

I like this approach. If someone would care to start this without me
in the meantime (I'm not getting much free time now that some of the
projects I'm working on are reaching the deployment stages, I'm having
less and less time to spare for open source development).

Thanks very much Glyn!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Pion's HTTPParser

[Michael D. <mi...@mi...>]

On Dec 11, 2007, at 12:26 AM, Dean Michael Berris wrote:

> Hi Mike!
>
> On Dec 11, 2007 10:40 AM, Michael Dickey <mi...@mi...> wrote:
>> Dean and I have been talking on the boost development list about ways
>> to integrate Pion code into the current cpp-netlib structure.  Seemed
>> like a good idea to move that discussion over to this list instead.
>
> I agree, though I'd also like to have other people in the Boost
> mailing list involved somehow. I like the input that we get there, and
> I'm thankful that the discussion has brought out interesting insights
> from people in the list. :)

I'm new to the Boost list, so I just wasn't sure about overwhelming it  
messages on this topic -- in particular as we get more into  
implementation details.  I can re-post my message there though if you  
think others would be interested in chiming in.

...
>> In any case, if we could figure out how to merge this functionality
>> over I'd be happy to switch over to using cpp-netlib in Pion instead
>> of our own message-like classes.
>>
>
> Sweet! That sounds like good motivation for me to actually write more
> documentation, try porting your better parser, and see how else we can
> improve on decoupling the logging/networking/etc. from the actual
> parsing.

Great, feel free to use as much or little of it as you like!  =)

And of course, let me know if you have any questions..

> Just a question: why shouldn't we be using Boost.Spirit for this  
> sort of thing?

The main reason I didn't use it is that I'm not familiar with  
Boost.Spirit, and the parsing code was original based on Chris'  
http_server examples in ASIO (which do not use Spirit).

I got the impression from reading through the Spirit pages that it  
does incur a performance penalty, and I wanted to make everything in  
Pion as fast as possible.  Also, I wasn't clear if Spirit could handle  
the incremental processing needs.  Namely, the parser needs to be able  
to consume as few as 1 byte at a time to make it asynchronous, low- 
memory and HTTP/1.1 compatible.

Take care,
-Mike

[cpp-netlib-devel] Sourceforge tracker

[Glyn M. <gly...@gm...>]

Dear group,


I've added a category and group to the feature tracker following on from the
discussion about the HTTPParser from Pion.  Furthermore, I also added a task
(HTTP integration).

I'd like to know your opinions on how to best organise the SVN repository,
tracker and task manager.  Currently, my thoughts are:

A task corresponds to a separate branch in SVN (e.g. HTTP integration,
version 1.0 etc.).  Feature requests are assigned to a group which
corresponds to a task.  A feature request can also belong to a category
which might be more descriptive (e.g. documentation, security ...)

Is there anything else?  If anyone wants to start working on something,
create a task and an SVN branch and use this (I don't have access to the SVN
repository here, so if someone wants to create a branch for the HTTP
integration, please go ahead).  If you want me to add more categories and
tasks, let me know.

Regards,
Glyn

Re: [cpp-netlib-devel] Pion's HTTPParser

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

On Dec 11, 2007 4:33 PM, Glyn Matthews <gly...@gm...> wrote:
>
> Hi,
>
> > Please add a task in the tracker -- Glyn, do you have an idea how to
> > best use the Sourceforge Trackers?
>
> Yes, I see the feature has already been added but I'll configure the tracker
> a bit better to make it easier for us to use.
> G
>

Thanks Glyn!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Pion's HTTPParser

[Glyn M. <gly...@gm...>]

Hi,

Please add a task in the tracker -- Glyn, do you have an idea how to
> best use the Sourceforge Trackers?


Yes, I see the feature has already been added but I'll configure the tracker
a bit better to make it easier for us to use.
G

Re: [cpp-netlib-devel] Pion's HTTPParser

[Alex O. <al...@gm...>]

Hi

On Dec 11, 2007 9:22 AM, Dean Michael Berris <mik...@gm...> wrote:
> Hi Alex,
>
> On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote:
> >
> > i had looked into protocol/http/impl/request.hpp and had seen, that it
> > include URI parser. i think, that it better to implement URI parser in
> > their own namespace, as it could be used not only in http parsing, but
> > also in other places.
>
> Yup, I agree. I intend to refactor those out later -- but that would
> mean there would be tons of tests just to make sure that the parser is
> correct. That sounds like a lot of work, but if you'd like to try that
> out, please be my guest. :)

Yes, i for a long time looking for this project in SVN

> > Also, may be it will be useful during implementation - may be not hard
> > code "HTTP" protocol name in parser, but specify it as template
> > parameter? I suggest this, as some other protocols (such as ICAP), use
> > the same structure as HTTP, but different protocol name
> >
>
> This makes sense.
>
> Please add a task in the tracker -- Glyn, do you have an idea how to
> best use the Sourceforge Trackers?

Ok, add

> > P.S. i has almost working http request/response parsers, but i has
> > some problems with mixing boost::spirit + std::multimap.
> > I use following structures to hold information about request/response
> > (and corresponding parsers):
> I'm not sure what you're trying to accomplish though, so it's hard to
> comment. I've found out that with Boost.Spirit, it's usually best that
> you use semantic actions built with Phoenix. I'm not sure if there
> have been major changes with Phoenix the past few months, and having
> seen Boost.Spirit being release-ready in Boost Trunk, it would be a
> good idea to use those instead.
>
> Having said that, we should be updating the sources that require
> Fusion -- there have been breaking changes with the directory
> structure since we last tested the code, but unfortunately I don't
> have time yet to get to those.

Ok, i switch to fusion & phoenix, and try to help you in implementing
http parsers - i'm currently writer several projects, that require
http parsing, so we'll has good test cases ;-)

-- 
With best wishes,                    Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/

Re: [cpp-netlib-devel] Pion's HTTPParser

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

Hi Mike!

On Dec 11, 2007 10:40 AM, Michael Dickey <mi...@mi...> wrote:
> Dean and I have been talking on the boost development list about ways
> to integrate Pion code into the current cpp-netlib structure.  Seemed
> like a good idea to move that discussion over to this list instead.
>

I agree, though I'd also like to have other people in the Boost
mailing list involved somehow. I like the input that we get there, and
I'm thankful that the discussion has brought out interesting insights
from people in the list. :)

> I think that the best starting point would be to focus on merging over
> Pion's HTTPParser class:
>
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8hpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8cpp-source.html
>
> It's an incremental parser that can be used for both 1.0 and 1.1, and
> also for both requests and responses.  It seems like you could just
> reformat & rename it for boost's style standards, remove the logging
> support, and use cpp-netlib's http::request and http::response classes
> in favor of Pion's HTTPRequest and HTTPResponse (so long as they
> support the same functionality).
>
> FYI: one major thing currently missing in the parser is being able to
> parse HTTP/1.1 chunks.  This is supported in the "Writer" classes (see
> below) but not in our underlying parsing code.  Someone is working on
> this right now actually, and we will probably have it in there by the
> end of the week.
>
> To see an example of how we use it to parse a request or response
> message, check out the HTTPMessage::receive() implementation:
>
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_message_8cpp-source.html
>
> Or for an asynchronous usage example, check out the HTTPReader class:
>
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8hpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8cpp-source.html
>
> Or the HTTPRequestReader and HTTPResponseReader classes:
>
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_reader_8hpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_reader_8hpp-source.html
>
> If you're interested in Pion's asynchronous sending code, just replace
> "Reader" in any of these names with "Writer":
>
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8hpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8cpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_writer_8hpp-source.html
> http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_writer_8hpp-source.html
>
> I'd really love to get more involve and work directly on converting
> this code over, but honestly I'm not all that great with templates and
> doing things right for a header-only approach.  Your basic_message
> code definitely looks cooler and more extensible but I'm having a
> little trouble fully grok'ing it.  Plus, I figure you would probably
> do things differently than I =)
>

I'll go ahead and schedule this for later -- we should really be using
the Sourceforge tracker for these "TODO's" .

> In any case, if we could figure out how to merge this functionality
> over I'd be happy to switch over to using cpp-netlib in Pion instead
> of our own message-like classes.
>

Sweet! That sounds like good motivation for me to actually write more
documentation, try porting your better parser, and see how else we can
improve on decoupling the logging/networking/etc. from the actual
parsing.

Just a question: why shouldn't we be using Boost.Spirit for this sort of thing?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Pion's HTTPParser

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

Hi Alex,

On Dec 11, 2007 4:14 PM, Alex Ott <al...@gm...> wrote:
>
> i had looked into protocol/http/impl/request.hpp and had seen, that it
> include URI parser. i think, that it better to implement URI parser in
> their own namespace, as it could be used not only in http parsing, but
> also in other places.

Yup, I agree. I intend to refactor those out later -- but that would
mean there would be tons of tests just to make sure that the parser is
correct. That sounds like a lot of work, but if you'd like to try that
out, please be my guest. :)

> Also, may be it will be useful during implementation - may be not hard
> code "HTTP" protocol name in parser, but specify it as template
> parameter? I suggest this, as some other protocols (such as ICAP), use
> the same structure as HTTP, but different protocol name
>

This makes sense.

Please add a task in the tracker -- Glyn, do you have an idea how to
best use the Sourceforge Trackers?

> P.S. i has almost working http request/response parsers, but i has
> some problems with mixing boost::spirit + std::multimap.
> I use following structures to hold information about request/response
> (and corresponding parsers):
>
>         struct Version {
>                 std::string   protocol;
>                 unsigned int  major;
>                 unsigned int  minor;
>         };
>
>         struct Common {
>                 Version version;
>                 typedef std::multimap<std::string,std::string> headers_t;
>                 headers_t headers;
>                 std::string body;  // may be will replaced with vector<char>
>         } ;
>         struct Request : public Common {
>                 URI url;
>                 std::string command;
>         } ;
>         struct Response : public Common {
>                 std::string textStatus;
>                 uint16_t    intStatus;
>         } ;
>

I'm not sure what you're trying to accomplish though, so it's hard to
comment. I've found out that with Boost.Spirit, it's usually best that
you use semantic actions built with Phoenix. I'm not sure if there
have been major changes with Phoenix the past few months, and having
seen Boost.Spirit being release-ready in Boost Trunk, it would be a
good idea to use those instead.

Having said that, we should be updating the sources that require
Fusion -- there have been breaking changes with the directory
structure since we last tested the code, but unfortunately I don't
have time yet to get to those.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Pion's HTTPParser

[Alex O. <al...@gm...>]

Hello all

Not directly related to the pion http parser

i had looked into protocol/http/impl/request.hpp and had seen, that it
include URI parser. i think, that it better to implement URI parser in
their own namespace, as it could be used not only in http parsing, but
also in other places.
Also, may be it will be useful during implementation - may be not hard
code "HTTP" protocol name in parser, but specify it as template
parameter? I suggest this, as some other protocols (such as ICAP), use
the same structure as HTTP, but different protocol name

P.S. i has almost working http request/response parsers, but i has
some problems with mixing boost::spirit + std::multimap.
I use following structures to hold information about request/response
(and corresponding parsers):

	struct Version {
		std::string   protocol;
		unsigned int  major;
		unsigned int  minor;
	};

	struct Common {
		Version version;
		typedef std::multimap<std::string,std::string> headers_t;
		headers_t headers;
		std::string body;  // may be will replaced with vector<char>
	} ;
	struct Request : public Common {
		URI url;
		std::string command;
	} ;
	struct Response : public Common {
		std::string textStatus;
		uint16_t    intStatus;
	} ;


-- 
With best wishes,                    Alex Ott, MBA
http://alexott.blogspot.com/
http://alexott-ru.blogspot.com/
http://content-filtering.blogspot.com/
http://xtalk.msk.su/~ott/

[cpp-netlib-devel] Pion's HTTPParser

[Michael D. <mi...@mi...>]

Dean and I have been talking on the boost development list about ways  
to integrate Pion code into the current cpp-netlib structure.  Seemed  
like a good idea to move that discussion over to this list instead.

I think that the best starting point would be to focus on merging over  
Pion's HTTPParser class:

http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8hpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_parser_8cpp-source.html

It's an incremental parser that can be used for both 1.0 and 1.1, and  
also for both requests and responses.  It seems like you could just  
reformat & rename it for boost's style standards, remove the logging  
support, and use cpp-netlib's http::request and http::response classes  
in favor of Pion's HTTPRequest and HTTPResponse (so long as they  
support the same functionality).

FYI: one major thing currently missing in the parser is being able to  
parse HTTP/1.1 chunks.  This is supported in the "Writer" classes (see  
below) but not in our underlying parsing code.  Someone is working on  
this right now actually, and we will probably have it in there by the  
end of the week.

To see an example of how we use it to parse a request or response  
message, check out the HTTPMessage::receive() implementation:

http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_message_8cpp-source.html

Or for an asynchronous usage example, check out the HTTPReader class:

http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8hpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_reader_8cpp-source.html

Or the HTTPRequestReader and HTTPResponseReader classes:

http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_reader_8hpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_reader_8hpp-source.html

If you're interested in Pion's asynchronous sending code, just replace  
"Reader" in any of these names with "Writer":

http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8hpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_writer_8cpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_request_writer_8hpp-source.html
http://pion.atomiclabs.com/files/pion-net/net/doc/html/_h_t_t_p_response_writer_8hpp-source.html

I'd really love to get more involve and work directly on converting  
this code over, but honestly I'm not all that great with templates and  
doing things right for a header-only approach.  Your basic_message  
code definitely looks cooler and more extensible but I'm having a  
little trouble fully grok'ing it.  Plus, I figure you would probably  
do things differently than I =)

In any case, if we could figure out how to merge this functionality  
over I'd be happy to switch over to using cpp-netlib in Pion instead  
of our own message-like classes.

Take care,
-Mike

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

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

Hi Reetesh,

On Dec 1, 2007 2:07 AM, Reetesh Mukul <ree...@gm...> wrote:
> Yes now I got it. Actually I was thinking in different way. Suppose I have a
> http socket (which is on top of TCP socket), then one way to use it will be,
>
> http h("www.boost.org ");
> h >> receive_msg;
>
> Here h does not implies the inherent socket, it implies that h is the source
> of message, a kind of node.

This idiom, although very well meant, does not really apply to the
networking concept. Here's a couple of reasons why:

1. The istream/ostream family of objects in the STL are sources of raw
data -- they do not by any means perform any special processing on the
data except for formatting or conversion. This makes the underlying
implementation simple and considerably light (or cannot be made any
lighter).

2. The above construct doesn't show the protocol specific method of
retrieving the message. In HTTP you have a myriad of requests and
replies. For example, does the above sample imply a 'GET' request?
What if you want to perform a 'POST' request, how do you construct
your stream then? For example, you want to use a persistent connection
(HTTP 1.1) and want to send 'GET' and 'POST' requests over the same
connection, would that be possible with the above construct? Even for
SMTP this idiom will not work because you have a myriad of requests
and replies that simply slapping a stream on top of a connection
doesn't solve the problem.

The way I chose to implement this was with an explicit 'Client'
object, which specifies protocol specific methods precisely for
getting and sending messages over an implicit channel. In the latest
version from trunk, you should be able to see the intended idiom,
which looks like the following:

    using namespace boost::network;
    http::request request("http://boost.org/");
    http::client client_;
    http::response response_;
    response_ = client_.get(request);

This can easily be extended so that the following will also be
consistent with the interface:

    using namespace boost::network;
    http::request request("http://boost.org/");
    http::client client_;
    http::response response_;
    std::map<std::string, std::string> post_map;
    post_map["username"] = "me";
    post_map["password"] = "my_password";
    response_ = client_.post(request, post_map);

We can even implement the 'PUT' and 'DELETE' methods for HTTP, for a
REST aware client.

> Ofcourse this means we need to keep information
> to track data source of receive_msg. Also your http_proxy example points
> towards need of sender,receiver in message class. Still I feel we may need
> to have empty structures for sender, receiver in some case; through some
> template parameters.
>

You can currently actually do this in the cpp-netlib -- you can create
your own message specialization by using the tag parameter of the
basic_message type.

> I will keep paradigm of cpp-network for xmpp library also.
>

If you still have questions about the intended design, please keep the
questions and suggestions coming.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Yes now I got it. Actually I was thinking in different way. Suppose I have a
http socket (which is on top of TCP socket), then one way to use it will be,

http h("www.boost.org");
h >> receive_msg;

Here h does not implies the inherent socket, it implies that h is the source
of message, a kind of node. Ofcourse this means we need to keep information
to track data source of receive_msg. Also your http_proxy example points
towards need of sender,receiver in message class. Still I feel we may need
to have empty structures for sender, receiver in some case; through some
template parameters.

I will keep paradigm of cpp-network for xmpp library also.

Regards,
Reetesh Mukul

On 11/30/07, Dean Michael Berris <mik...@gm...> wrote:
>
> On Nov 30, 2007 7:03 PM, Reetesh Mukul <ree...@gm...> wrote:
> > Sorry for late reply.
> >
> >  I may be wrong completely, nevertheless can't the socket on which we
> are
> > sending data can keep track of all messages (received or sent) by using
> some
> > kind of hash_map/multiindex. After all complete identity of a message
> over
> > network depends on who sends it and who receives it. If one needs to
> keep
> > this track there can be provision of a table <sender, receiver,
> message&>
> >
>
> I don't think storing messages should be the concern of the networking
> library. If the client code wants to store messages, they should have
> to do it using their own strategy. The networking library should
> facilitate the transfer of data, but not the management of
> sent/received messages.
>
> And no, I don't think a message that came from the same socket
> necessarily have to come from the same source. Consider HTTP messages
> that came through a single HTTP proxy, but were retrieved from a
> different source website. Actually, in all cases a message should be
> associated with a source and destination regardless of the actual
> channel from which it came: consider a message that may come from a
> file (email, XML, etc.) which can be associated with a source (email
> address, URI, etc) and a destination (email address, ip address,
> etc.), but can be transferred through many different means (via TCP/IP
> sockets, UNIX domain sockets, UDP, etc.).
>
> So state management should not be within the scope of the networking
> library -- anything related to application specific logic should be
> application specific.
>
> I hope this makes sense.
>
> --
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.
> [http://cplusplus-soup.blogspot.com/]
> [mik...@gm...]
> [+63 928 7291459]
> [+1 408 4049523]
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

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

On Nov 30, 2007 7:03 PM, Reetesh Mukul <ree...@gm...> wrote:
> Sorry for late reply.
>
>  I may be wrong completely, nevertheless can't the socket on which we are
> sending data can keep track of all messages (received or sent) by using some
> kind of hash_map/multiindex. After all complete identity of a message over
> network depends on who sends it and who receives it. If one needs to keep
> this track there can be provision of a table <sender, receiver, message&>
>

I don't think storing messages should be the concern of the networking
library. If the client code wants to store messages, they should have
to do it using their own strategy. The networking library should
facilitate the transfer of data, but not the management of
sent/received messages.

And no, I don't think a message that came from the same socket
necessarily have to come from the same source. Consider HTTP messages
that came through a single HTTP proxy, but were retrieved from a
different source website. Actually, in all cases a message should be
associated with a source and destination regardless of the actual
channel from which it came: consider a message that may come from a
file (email, XML, etc.) which can be associated with a source (email
address, URI, etc) and a destination (email address, ip address,
etc.), but can be transferred through many different means (via TCP/IP
sockets, UNIX domain sockets, UDP, etc.).

So state management should not be within the scope of the networking
library -- anything related to application specific logic should be
application specific.

I hope this makes sense.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Reusable filter chain design problem.

[Reetesh M. <ree...@gm...>]

I also have similar views.

Actually there was an effort called Boost.Join (
http://channel.sourceforge.net/) which dealt with similar set of problem. Of
course signal network library also gives hints towards possible design
methodologies.

For example if we have an http socket, and suppose we have to parse for an
image object, we can have,

read_until(http,image);

or http >> image.

If we have multiple objects say image, table etc., we can have following
model,

http >> +(image | model).

boost spirit 2 has output/input models like karma, lex we need similar type
of modules here also. In future we may look for embedding pi-calculus (
http://en.wikipedia.org/wiki/Pi-calculus) in C++, the way lambda calculus
has been embedded in phoenix.

Regards,
Reetesh Mukul

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Sorry for late reply.

 I may be wrong completely, nevertheless can't the socket on which we are
sending data can keep track of all messages (received or sent) by using some
kind of hash_map/multiindex. After all complete identity of a message over
network depends on who sends it and who receives it. If one needs to keep
this track there can be provision of a table <sender, receiver, message&>

Regards,
Reetesh Mukul

Re: [cpp-netlib-devel] Reusable filter chain design problem.

[Stjepan R. <st...@as...>]

On Nov 27, 2007 9:37 AM, Christian Henning <chh...@gm...> wrote:
> Hi there,
>
> doesn't this idea sound like the signal network which was part of this
> year's SoC? Don't know the status of this project, though.
>
> Christian

It turned into the Dataflow library, and yes - the filter chaining
should be within its scope.  At the moment you can do it using the
layer based on Boost.Signals - see the "motivation and advantages"
section for a simple filter example (there are other examples of
filter chains as well):

http://dancinghacker.com/code/dataflow/

The Boost.Signals approach might not be the best for the use case you
mention here - but I am planning to expand the library with another
(perhaps more suitable) dataflow layer, and any feedback on what is
useful or lacking in what's currently supported by the library would
be greatly appreciated!

Regards,

Stjepan

Re: [cpp-netlib-devel] Reusable filter chain design problem.

[Christian H. <chh...@gm...>]

SGkgdGhlcmUsCgpkb2Vzbid0IHRoaXMgaWRlYSBzb3VuZCBsaWtlIHRoZSBzaWduYWwgbmV0d29y
ayB3aGljaCB3YXMgcGFydCBvZiB0aGlzCnllYXIncyBTb0M/IERvbid0IGtub3cgdGhlIHN0YXR1
cyBvZiB0aGlzIHByb2plY3QsIHRob3VnaC4KCkNocmlzdGlhbgoKT24gTm92IDI3LCAyMDA3IDEw
OjU4IEFNLCBBbGV4IE90dCA8YWxleG90dEBnbWFpbC5jb20+IHdyb3RlOgo+IEhlbGxvCj4KPiBN
YXkgYmUgdGFrZSBpbnRvIGFjY291bnQgZGVzaWduIG9mIGJvb3N0Lmlvc3RyZWFtcz8gQWxzbyBt
YXkgYmUgZ29vZAo+IGlkZWEgdG8gbG9vayBvbiBkZXNpZ24gb2YgY2hhaW5zIGluIEFDRQo+Cj4g
T24gTm92IDI3LCAyMDA3IDI6NTggQU0sIMGss8cgPHJoeXRobS5tYWlsQGdtYWlsLmNvbT4gd3Jv
dGU6Cj4gPiBIaSwgYWxsCj4gPgo+ID4gSSBoYXZlIHBvc3RlZCB0aGlzIGluIGFzaW8gdXNlciBn
cm91cC4gIEFuZCBJIHRoaW5rIGl0IGlzIGFsc28gaW1wb3J0YW50Cj4gPiBmb3IgY3BwLW5ldGxp
Yi4KPiA+Cj4gPiBJIHRoaW5rIGZpbHRlciBjaGFpbiBpcyBhbiBpbXBvcnRhbnQgZmFjaWxpdHkg
Zm9yIGFsbW9zdCBldmVyeSBzb21lIHdoYXQKPiA+IGNvbXBsaWNhdGVkIG5ldHdvcmsgYXBwbGlj
YXRpb24uIFNheSwgSSB3YW50Cj4gPgo+ID4gMS4gZG8gUkM0IGVuY3J5cHRpb24vZGVjcnlwdGlv
biwKPiA+IDIuIHppcC91bnppcCB0aGUgYnl0ZSBzdHJlYW0sCj4gPiAzLiBlbmNvZGUvZGVjb2Rl
IGEgcHJvdG9jb2wgc3BlY2lmaWMgY2xhc3MgaW5zdGFuY2UgaW50by9mcm9tIHBsYWluIGJ5dGUK
PiA+IHN0cmVhbS4KPiA+Cj4gPiBUaGVuIHdlIG5lZWQgMyBmaWx0ZXJzOiBhbiBSQzQgZmlsdGVy
LCBhIGNvbXByZXNzaW9uIGZpbHRlciwgYW5kIGEKPiA+IHByb3RvY29sIGNvZGVjIGZpbHRlci4g
V2UgYXNzZW1ibGUgdGhlc2UgZmlsdGVycyBpbnRvIGEgZmlsdGVyIGNoYWluLAo+ID4gYW5kIGF0
dGFjaCB0aGUgZmlsdGVyIGNoYWluIHRvIHNlc3Npb25zLgo+ID4KPiA+IFRoZXJlIGFyZSBzZXZl
cmFsIGNob2ljZXMsIHNheSBjb21waWxlIHRpbWUgc3RhdGljIGZpbHRlciBjaGFpbiBvcgo+ID4g
cnVudGltZSBhc3NlbWJsZWQgZHluYW1pYyBmaWx0ZXIgY2hhaW4/IEFuZCBmaWx0ZXJzIG9mdGVu
IG1haW50YWlucwo+ID4gc2Vzc2lvbiBzcGVjaWZpYyBzdGF0ZXMsIGlmIHdlIHN0b3JlIHRoZSBz
dGF0ZXMgaW4gdGhlIGZpbHRlcnMsIHdlCj4gPiBzaG91bGQgbWFpbnRhaW4gb25lIGZpbHRlciBj
aGFpbiBwZXIgc2Vzc2lvbi4gSWYgd2Ugc3RvcmUgdGhlIHN0YXRlcyBpbgo+ID4gdGhlIHNlc3Np
b24gb2JqZWN0LCBhbmQgbWFrZSBhbGwgZmlsdGVycyBzdGF0ZWxlc3MsIHRoZW4gYWxsIHNlc3Np
b24gY2FuCj4gPiBzaGFyZSBhIHNpbmdsZSBmaWx0ZXIgY2hhaW4uIEJ1dCB0aGUgc2Vzc2lvbiBv
YmplY3QgbXVzdCBtZWV0IHRoZQo+ID4gY29uY2VwdCB0aGF0IGFsbCB0aGUgZmlsdGVycyByZXF1
aXJlcy4gU2F5LCB0aGUgUkM0IGVuY29kZXIvZGVjb2RlciBwYWlyCj4gPiBhcmUgbm90IHN0YXRl
bGVzcywgdGh1cyBjYW5ub3QgYmUgc3RvcmVkIGluIHRoZSByYzRfZmlsdGVyIGluc3RhbmNlLCBh
bmQKPiA+IHJjNF9maWx0ZXIgbWF5IHJlcXVpcmVzIHRoZSBzZXNzaW9uIG9iamVjdCBoYXZpbmcg
dHdvIHB1YmxpYyBtZXRob2Q6Cj4gPgo+ID4gICAgICByYzRfZW5jb2RlciYgZ2V0X3JjNF9lbmNv
ZGVyKCk7Cj4gPiAgICAgIHJjNF9kZWNvZGVyJiBnZXRfcmM0X2RlY29kZXIoKTsKPiA+Cj4gPiBX
aGF0IGRvIHlvdSB0aGluaz8gQW5kIEkgcmVjb21tZW5kIGEgZ2xhbmNlIGF0IHRoZSBBcGFjaGUg
TUlOQSBwcm9qZWN0LAo+ID4gd2hpY2ggaGF2ZSBhIHJhdGhlciBmbGV4aWJsZSBmaWx0ZXIgY2hh
aW4gZmFjaWxpdHkuIEhlcmUncyB0aGUgc2l0ZToKPiA+Cj4gPiAgICAgIGh0dHA6Ly9taW5hLmFw
YWNoZS5vcmcvCj4gPgo+ID4KPiA+IENoZWVycwo+ID4gQ2hlbmcKPiA+Cj4gPgo+ID4KPiA+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0KPiA+IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogTWlj
cm9zb2Z0Cj4gPiBEZWZ5IGFsbCBjaGFsbGVuZ2VzLiBNaWNyb3NvZnQoUikgVmlzdWFsIFN0dWRp
byAyMDA1Lgo+ID4gaHR0cDovL2Nsay5hdGRtdC5jb20vTVJUL2dvL3ZzZTAxMjAwMDAwNzBtcnQv
ZGlyZWN0LzAxLwo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KPiA+IENwcC1uZXRsaWItZGV2ZWwgbWFpbGluZyBsaXN0Cj4gPiBDcHAtbmV0bGliLWRl
dmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5u
ZXQvbGlzdHMvbGlzdGluZm8vY3BwLW5ldGxpYi1kZXZlbAo+ID4KPiA+Cj4KPgo+Cj4gLS0KPiBX
aXRoIGJlc3Qgd2lzaGVzLCAgICAgICAgICAgICAgICAgICAgQWxleCBPdHQsIE1CQQo+IGh0dHA6
Ly9hbGV4b3R0LmJsb2dzcG90LmNvbS8KPiBodHRwOi8vYWxleG90dC1ydS5ibG9nc3BvdC5jb20v
Cj4gaHR0cDovL2NvbnRlbnQtZmlsdGVyaW5nLmJsb2dzcG90LmNvbS8KPiBodHRwOi8veHRhbGsu
bXNrLnN1L35vdHQvCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyBTRi5uZXQgZW1haWwgaXMg
c3BvbnNvcmVkIGJ5OiBNaWNyb3NvZnQKPiBEZWZ5IGFsbCBjaGFsbGVuZ2VzLiBNaWNyb3NvZnQo
UikgVmlzdWFsIFN0dWRpbyAyMDA1Lgo+IGh0dHA6Ly9jbGsuYXRkbXQuY29tL01SVC9nby92c2Uw
MTIwMDAwMDcwbXJ0L2RpcmVjdC8wMS8KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+IENwcC1uZXRsaWItZGV2ZWwgbWFpbGluZyBsaXN0Cj4gQ3BwLW5l
dGxpYi1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9jcHAtbmV0bGliLWRldmVsCj4KPgo=

Re: [cpp-netlib-devel] Reusable filter chain design problem.

[Alex O. <al...@gm...>]

SGVsbG8KCk1heSBiZSB0YWtlIGludG8gYWNjb3VudCBkZXNpZ24gb2YgYm9vc3QuaW9zdHJlYW1z
PyBBbHNvIG1heSBiZSBnb29kCmlkZWEgdG8gbG9vayBvbiBkZXNpZ24gb2YgY2hhaW5zIGluIEFD
RQoKT24gTm92IDI3LCAyMDA3IDI6NTggQU0sIMGss8cgPHJoeXRobS5tYWlsQGdtYWlsLmNvbT4g
d3JvdGU6Cj4gSGksIGFsbAo+Cj4gSSBoYXZlIHBvc3RlZCB0aGlzIGluIGFzaW8gdXNlciBncm91
cC4gIEFuZCBJIHRoaW5rIGl0IGlzIGFsc28gaW1wb3J0YW50Cj4gZm9yIGNwcC1uZXRsaWIuCj4K
PiBJIHRoaW5rIGZpbHRlciBjaGFpbiBpcyBhbiBpbXBvcnRhbnQgZmFjaWxpdHkgZm9yIGFsbW9z
dCBldmVyeSBzb21lIHdoYXQKPiBjb21wbGljYXRlZCBuZXR3b3JrIGFwcGxpY2F0aW9uLiBTYXks
IEkgd2FudAo+Cj4gMS4gZG8gUkM0IGVuY3J5cHRpb24vZGVjcnlwdGlvbiwKPiAyLiB6aXAvdW56
aXAgdGhlIGJ5dGUgc3RyZWFtLAo+IDMuIGVuY29kZS9kZWNvZGUgYSBwcm90b2NvbCBzcGVjaWZp
YyBjbGFzcyBpbnN0YW5jZSBpbnRvL2Zyb20gcGxhaW4gYnl0ZQo+IHN0cmVhbS4KPgo+IFRoZW4g
d2UgbmVlZCAzIGZpbHRlcnM6IGFuIFJDNCBmaWx0ZXIsIGEgY29tcHJlc3Npb24gZmlsdGVyLCBh
bmQgYQo+IHByb3RvY29sIGNvZGVjIGZpbHRlci4gV2UgYXNzZW1ibGUgdGhlc2UgZmlsdGVycyBp
bnRvIGEgZmlsdGVyIGNoYWluLAo+IGFuZCBhdHRhY2ggdGhlIGZpbHRlciBjaGFpbiB0byBzZXNz
aW9ucy4KPgo+IFRoZXJlIGFyZSBzZXZlcmFsIGNob2ljZXMsIHNheSBjb21waWxlIHRpbWUgc3Rh
dGljIGZpbHRlciBjaGFpbiBvcgo+IHJ1bnRpbWUgYXNzZW1ibGVkIGR5bmFtaWMgZmlsdGVyIGNo
YWluPyBBbmQgZmlsdGVycyBvZnRlbiBtYWludGFpbnMKPiBzZXNzaW9uIHNwZWNpZmljIHN0YXRl
cywgaWYgd2Ugc3RvcmUgdGhlIHN0YXRlcyBpbiB0aGUgZmlsdGVycywgd2UKPiBzaG91bGQgbWFp
bnRhaW4gb25lIGZpbHRlciBjaGFpbiBwZXIgc2Vzc2lvbi4gSWYgd2Ugc3RvcmUgdGhlIHN0YXRl
cyBpbgo+IHRoZSBzZXNzaW9uIG9iamVjdCwgYW5kIG1ha2UgYWxsIGZpbHRlcnMgc3RhdGVsZXNz
LCB0aGVuIGFsbCBzZXNzaW9uIGNhbgo+IHNoYXJlIGEgc2luZ2xlIGZpbHRlciBjaGFpbi4gQnV0
IHRoZSBzZXNzaW9uIG9iamVjdCBtdXN0IG1lZXQgdGhlCj4gY29uY2VwdCB0aGF0IGFsbCB0aGUg
ZmlsdGVycyByZXF1aXJlcy4gU2F5LCB0aGUgUkM0IGVuY29kZXIvZGVjb2RlciBwYWlyCj4gYXJl
IG5vdCBzdGF0ZWxlc3MsIHRodXMgY2Fubm90IGJlIHN0b3JlZCBpbiB0aGUgcmM0X2ZpbHRlciBp
bnN0YW5jZSwgYW5kCj4gcmM0X2ZpbHRlciBtYXkgcmVxdWlyZXMgdGhlIHNlc3Npb24gb2JqZWN0
IGhhdmluZyB0d28gcHVibGljIG1ldGhvZDoKPgo+ICAgICAgcmM0X2VuY29kZXImIGdldF9yYzRf
ZW5jb2RlcigpOwo+ICAgICAgcmM0X2RlY29kZXImIGdldF9yYzRfZGVjb2RlcigpOwo+Cj4gV2hh
dCBkbyB5b3UgdGhpbms/IEFuZCBJIHJlY29tbWVuZCBhIGdsYW5jZSBhdCB0aGUgQXBhY2hlIE1J
TkEgcHJvamVjdCwKPiB3aGljaCBoYXZlIGEgcmF0aGVyIGZsZXhpYmxlIGZpbHRlciBjaGFpbiBm
YWNpbGl0eS4gSGVyZSdzIHRoZSBzaXRlOgo+Cj4gICAgICBodHRwOi8vbWluYS5hcGFjaGUub3Jn
Lwo+Cj4KPiBDaGVlcnMKPiBDaGVuZwo+Cj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBUaGlzIFNG
Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE1pY3Jvc29mdAo+IERlZnkgYWxsIGNoYWxsZW5n
ZXMuIE1pY3Jvc29mdChSKSBWaXN1YWwgU3R1ZGlvIDIwMDUuCj4gaHR0cDovL2Nsay5hdGRtdC5j
b20vTVJUL2dvL3ZzZTAxMjAwMDAwNzBtcnQvZGlyZWN0LzAxLwo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gQ3BwLW5ldGxpYi1kZXZlbCBtYWlsaW5n
IGxpc3QKPiBDcHAtbmV0bGliLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8v
bGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2NwcC1uZXRsaWItZGV2ZWwKPgo+
CgoKCi0tIApXaXRoIGJlc3Qgd2lzaGVzLCAgICAgICAgICAgICAgICAgICAgQWxleCBPdHQsIE1C
QQpodHRwOi8vYWxleG90dC5ibG9nc3BvdC5jb20vCmh0dHA6Ly9hbGV4b3R0LXJ1LmJsb2dzcG90
LmNvbS8KaHR0cDovL2NvbnRlbnQtZmlsdGVyaW5nLmJsb2dzcG90LmNvbS8KaHR0cDovL3h0YWxr
Lm1zay5zdS9+b3R0Lwo=

[cpp-netlib-devel] Reusable filter chain design problem.

[<rhy...@gm...>]

Hi, all

I have posted this in asio user group.  And I think it is also important 
for cpp-netlib.

I think filter chain is an important facility for almost every some what 
complicated network application. Say, I want

1. do RC4 encryption/decryption,
2. zip/unzip the byte stream,
3. encode/decode a protocol specific class instance into/from plain byte 
stream.

Then we need 3 filters: an RC4 filter, a compression filter, and a 
protocol codec filter. We assemble these filters into a filter chain, 
and attach the filter chain to sessions.

There are several choices, say compile time static filter chain or 
runtime assembled dynamic filter chain? And filters often maintains 
session specific states, if we store the states in the filters, we 
should maintain one filter chain per session. If we store the states in 
the session object, and make all filters stateless, then all session can 
share a single filter chain. But the session object must meet the 
concept that all the filters requires. Say, the RC4 encoder/decoder pair 
are not stateless, thus cannot be stored in the rc4_filter instance, and 
rc4_filter may requires the session object having two public method:

     rc4_encoder& get_rc4_encoder();
     rc4_decoder& get_rc4_decoder();

What do you think? And I recommend a glance at the Apache MINA project, 
which have a rather flexible filter chain facility. Here's the site:

     http://mina.apache.org/


Cheers
Cheng

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

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

Hi Reetesh!

On Nov 26, 2007 4:57 AM, Reetesh Mukul <ree...@gm...> wrote:

> Hi Dean and All,
>
> I have been going through the code development in cpp-netlib for last 6
> months. I have been experimenting on XMPP for a while, (http://tarang.xmpp.googlepages.com/
> ) and have done some crude implementations (see svn). With time, I am
> planning to stick to cpp-netlib codes, for their is no meaning of
> implementing things in XMPP which are already in cpp-netlib. That said, now
> onwards I will like to put my view points (and also codes in cpp-netlib ;-)
> ), for it will have direct impact on XMPP design. I have some points in my
> mind:-
>

I will take a look. Thanks for the link! I'll try to answer the questions
below:


>
>
>    1. basic_message<...> class resembles basic_string<...> class. I
>    think this class very well fits in the whole scheme. However I could not
>    comprehend the intent of _source, _destination. In particular cases they can
>    be mail-id, server-id; some kind of classes. They need not be necessarily
>    std::string.
>
> basic_message<...> should have a source and a destination, for
identification purposes. So any message should be associated with a source
and a destination. However, the use of std::string was merely for
convenience. The idea is that you should be able to change the
implementation of basic_message<...> by  supplying the appropriate template
argument tag (blob type maybe) for specialization for many different types
of messages. For example, there are messages that use integers for source
and destination, have headers that have 1:1 mapping between keys and values,
etc.

>
>    1.
>    2. basic_message<...> should be serializable over asio sockets.
>
> This can actually be implemented independent of a basic_message, or as a
decorator to the type. Therefore, there could be a wrapper type
serializable<...> which takes a template argument of type
basic_message<...>, which decorates the type basic_message<...> through
inheritance.

>
>    1.
>    2. There can be derived classes from basic_message<...> ---
>    basic_receiver_message<...>, basic_sender_message<...>. For
>    basic_receiver_message we can have functions like:-
>    read(socket&,basic_receiver_message<...>&) or read_until(socket&,
>    basic_receiver_message<...>&). Here read_until does not contain any
>    delimiter because basic_receive_message<...> will have this information.
>    Similar will be the functions around basic_sender_messag<...>
>
> This makes sense. However, all this boilerplate can be implemented in the
adapters layer, to turn basic_message<...> types into streamable or
iteratable streams. More about this when they crystallize in my mind.


>
>    1.
>    2. In future there should be modules to parse basic_message<...>
>    using boost::regex or boost::spirit or boost::xpressive.
>
> We've already started with a simple (very crude, possibly wrong) parser
for HTTP message handling.

>
>    1.
>
>
> Moreover we need project branches for rtp, rtsp, also. Though yes our
> prime requirement is http.


Either we branch, or we just implement the protocols independent of the
structure.

Thank you very much, and I hope the above explanations make sense!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

[cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Hi Dean and All,

I have been going through the code development in cpp-netlib for last 6
months. I have been experimenting on XMPP for a while, (
http://tarang.xmpp.googlepages.com/) and have done some crude
implementations (see svn). With time, I am planning to stick to cpp-netlib
codes, for their is no meaning of implementing things in XMPP which are
already in cpp-netlib. That said, now onwards I will like to put my view
points (and also codes in cpp-netlib ;-) ), for it will have direct impact
on XMPP design. I have some points in my mind:-


   1. basic_message<...> class resembles basic_string<...> class. I think
   this class very well fits in the whole scheme. However I could not
   comprehend the intent of _source, _destination. In particular cases they can
   be mail-id, server-id; some kind of classes. They need not be necessarily
   std::string.
   2. basic_message<...> should be serializable over asio sockets.
   3. There can be derived classes from basic_message<...> ---
   basic_receiver_message<...>, basic_sender_message<...>. For
   basic_receiver_message we can have functions like:-
   read(socket&,basic_receiver_message<...>&) or read_until(socket&,
   basic_receiver_message<...>&). Here read_until does not contain any
   delimiter because basic_receive_message<...> will have this information.
   Similar will be the functions around basic_sender_messag<...>
   4. In future there should be modules to parse basic_message<...> using
   boost::regex or boost::spirit or boost::xpressive.


Moreover we need project branches for rtp, rtsp, also. Though yes our prime
requirement is http.

Regards,
Reetesh Mukul

[cpp-netlib-devel] Pion Network Library 0.4.0

[Michael D. <mi...@mi...>]

Greetings,

I'm pleased to announce the 0.4.0 ("stable" beta) release of the Pion  
Network Library ("pion-net").  pion-net is a C++ development library  
for implementing lightweight HTTP interfaces.  pion-net is open source  
software licensed under the Boost Software License, which allows  
anyone to use it for free in both commercial and non-commercial  
applications.

pion-net uses the Boost and ASIO libraries to provide a web service  
plug-in framework for handling HTTP requests.  Although it is more  
geared towards server-side applications, the latest release includes  
client-side capabilities as well (for sending requests and receiving  
responses, either asynchronously or synchronously).  Support for HTTP  
1.0/1.1, pipelining, chunked encodings, query and cookie parsing is  
all included.  Currently, five development platforms are supported.

For more information, please see http://www.atomiclabs.com/pion/net/.

Take care,
-Mike

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

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

T24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1haWxAZ21haWwuY29tPiB3cm90ZToKPiBEZWFu
IE1pY2hhZWwgQmVycmlzIHdyb3RlOgo+ID4gT24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1h
aWxAZ21haWwuY29tPiB3cm90ZToKPiA+Cj4gPj4gSGksCj4gPj4KPiA+PiBBbHdheXMgZ2xhZCB0
byBzZWUgcHJvZ3Jlc3MgOi0pIEkndmUgY2hlY2tlZCB0aGUgY29kZSB1bmRlciBhIERlYmlhbgo+
ID4+IExpbnV4IGJveCB3aXRoIEJvb3N0IHRydW5rLCBhbmQgaXQgZmFpbHMgdG8gY29tcGlsZSwg
c2luY2UgcHRocmVhZCBpcwo+ID4+IHJlcXVpcmVkIGJ5IEJvb3N0LlN5c3RlbS4gSXQgaXMgZmFp
cmx5IGVhc3kgdG8gY29wZSB3aXRoLiBBZGQgdGhpcyBsaW5lCj4gPj4gdG8gdGhlIHRydW5rL2xp
YnMvbmV0d29yay90ZXN0L0phbWZpbGUudjIgZmlsZSBpbiB0aGUgcHJvamVjdCByZXF1aXJlbWVu
dHM6Cj4gPj4KPiA+PiAgICAgPHRvb2xzZXQ+Z2NjOjxzb3VyY2U+cHRocmVhZAo+ID4+Cj4gPj4g
VGhlbiB0aGUgY29kZSBjb21waWxlcy4gQnV0LCBJIGdvdCBsaW5raW5nIGVycm9ycywgYW5kIEkn
dmUgZ290IG5vIGlkZWEKPiA+PiBob3cgdG8gc2V0dGxlIHRoZW06Cj4gPj4KPiA+Pgo+ID4KPiA+
IEhvdyBhYm91dCBhZGRpbmcgPHRvb2xzZXQ+Z2NjOjxsaW5rZmxhZ3M+LWxwdGhyZWFkIGluIHRo
ZSByZXF1aXJlbWVudHMKPiA+Cj4gSSBmb3Jnb3QgdG8gbWVudGlvbiB0aGF0IGFub3RoZXIgbGlu
ZSBpcyBhbHNvIGFkZGVkOgo+Cj4gICAgbGliIHB0aHJlYWQgOwo+Cj4gSSB0cmllZCB0aGUgbGlu
a2ZsYWdzIHNldHRpbmcsIGFuZCBpdCB3b3Jrcy4gQWxsIHRlc3RzIHBhc3NlZC4gSSdsbAo+IGNo
ZWNrIGl0IGluIHNvb24gOi0pCgpTd2VldCEgVGhhbmtzIQoKLS0gCkRlYW4gTWljaGFlbCBDLiBC
ZXJyaXMKU29mdHdhcmUgRW5naW5lZXIsIEZyaWVuZHN0ZXIsIEluYy4KW2h0dHA6Ly9jcGx1c3Bs
dXMtc291cC5ibG9nc3BvdC5jb20vXQpbbWlraGFpbGJlcmlzQGdtYWlsLmNvbV0KWys2MyA5Mjgg
NzI5MTQ1OV0KWysxIDQwOCA0MDQ5NTIzXQo=

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

[<rhy...@gm...>]

Dean Michael Berris wrote:
> On 10/10/07, 连城 <rhy...@gm...> wrote:
>   
>> Hi,
>>
>> Always glad to see progress :-) I've checked the code under a Debian
>> Linux box with Boost trunk, and it fails to compile, since pthread is
>> required by Boost.System. It is fairly easy to cope with. Add this line
>> to the trunk/libs/network/test/Jamfile.v2 file in the project requirements:
>>
>>     <toolset>gcc:<source>pthread
>>
>> Then the code compiles. But, I got linking errors, and I've got no idea
>> how to settle them:
>>
>>     
>
> How about adding <toolset>gcc:<linkflags>-lpthread in the requirements
>   
I forgot to mention that another line is also added:

    lib pthread ;

I tried the linkflags setting, and it works. All tests passed. I'll 
check it in soon :-)
> of the tests Jamfile as well? This should fix it, though I'm not
> entirely sure -- couldn't test it at the moment.
>
> Please let me know what you see, and thanks for the tip! :)
>
>   

Re: [cpp-netlib-devel] Branching to Implement HTTP 1.0

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

T24gMTAvMTAvMDcsIOi/nuWfjiA8cmh5dGhtLm1haWxAZ21haWwuY29tPiB3cm90ZToKPiBIaSwK
Pgo+IEFsd2F5cyBnbGFkIHRvIHNlZSBwcm9ncmVzcyA6LSkgSSd2ZSBjaGVja2VkIHRoZSBjb2Rl
IHVuZGVyIGEgRGViaWFuCj4gTGludXggYm94IHdpdGggQm9vc3QgdHJ1bmssIGFuZCBpdCBmYWls
cyB0byBjb21waWxlLCBzaW5jZSBwdGhyZWFkIGlzCj4gcmVxdWlyZWQgYnkgQm9vc3QuU3lzdGVt
LiBJdCBpcyBmYWlybHkgZWFzeSB0byBjb3BlIHdpdGguIEFkZCB0aGlzIGxpbmUKPiB0byB0aGUg
dHJ1bmsvbGlicy9uZXR3b3JrL3Rlc3QvSmFtZmlsZS52MiBmaWxlIGluIHRoZSBwcm9qZWN0IHJl
cXVpcmVtZW50czoKPgo+ICAgICA8dG9vbHNldD5nY2M6PHNvdXJjZT5wdGhyZWFkCj4KPiBUaGVu
IHRoZSBjb2RlIGNvbXBpbGVzLiBCdXQsIEkgZ290IGxpbmtpbmcgZXJyb3JzLCBhbmQgSSd2ZSBn
b3Qgbm8gaWRlYQo+IGhvdyB0byBzZXR0bGUgdGhlbToKPgoKSG93IGFib3V0IGFkZGluZyA8dG9v
bHNldD5nY2M6PGxpbmtmbGFncz4tbHB0aHJlYWQgaW4gdGhlIHJlcXVpcmVtZW50cwpvZiB0aGUg
dGVzdHMgSmFtZmlsZSBhcyB3ZWxsPyBUaGlzIHNob3VsZCBmaXggaXQsIHRob3VnaCBJJ20gbm90
CmVudGlyZWx5IHN1cmUgLS0gY291bGRuJ3QgdGVzdCBpdCBhdCB0aGUgbW9tZW50LgoKUGxlYXNl
IGxldCBtZSBrbm93IHdoYXQgeW91IHNlZSwgYW5kIHRoYW5rcyBmb3IgdGhlIHRpcCEgOikKCi0t
IApEZWFuIE1pY2hhZWwgQy4gQmVycmlzClNvZnR3YXJlIEVuZ2luZWVyLCBGcmllbmRzdGVyLCBJ
bmMuCltodHRwOi8vY3BsdXNwbHVzLXNvdXAuYmxvZ3Nwb3QuY29tL10KW21pa2hhaWxiZXJpc0Bn
bWFpbC5jb21dClsrNjMgOTI4IDcyOTE0NTldClsrMSA0MDggNDA0OTUyM10K