|
From: Dean M. B. <mik...@gm...> - 2007-12-02 04:53:26
|
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]
|