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
>