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]