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