Re: [cpp-netlib-devel] Binary parsers

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

On Tue, Nov 4, 2008 at 8:12 PM, Rodrigo Madera <rod...@gm...> wrote:
>> What "buffer" class are you talking about?
>
> The class boost::asio::buffer was made for this.
>

And we use boost::asio::buffer's internally in the protocol
implementations. The messages merely represent data -- treat them as
data objects. If you check the HTTP client code, you will see that we
use the correct buffer types there provided by Asio. Transporting
whatever was gotten from the wire from the buffer to the user of the
client is what the message is supposed to be -- nothing more, nothing
less.

> I don't believe that this code can make it into Boost using strings for
> binary data.
>

I don't think so, considering that _you can customize the storage in
the message class to whatever you like depending on the protocol
you're implementing_ I believe the current design is definitely more
superior than using unweildy buffers in the message representation.

Think of it this way:

Request Message -> Client -> Client performs actions
Response Message <- Client

The type of the request message is dependent on what client you're
using. You can't use an http::request object to instruct an SNMP
client -- this will fail at compile time *and is the intended design
of the library*.

So if you're implementing your own protocol, you define the type of
the message you're going to use as a request and/or as a response
object instance. This means you -- as the implementor -- define
precisely what types to use within the message object specialization
that you need. If you think you need fixed-size buffers (or sometimes
bit-fields work too) then that's entirely up to you.

For instance, you can even change the signature of your specialization
of the basic_message class to reflect the signatures that you need.
For example, if you're thinking of using tuples of booleans to set
flags, then you can do that yourself:

  template <>
  struct basic_message<my_protocol_tag> {
    void header(tuple<bool, bool, bool> flags);
    tuple<bool, bool, bool> header();
  };

This makes your specialization of the message class even more specific
to your protocol.

That means, you may choose to use the default (that uses strings) or
you can write your own specialization depending on the tag you use to
distinguish your protocol from the other protocols.

> Anyways, it's your way of seeing things.

Actually, it's not just my way of seeing things. The design decision is:

1. Since it's the most common use case for most higher level protocols
like HTTP, SMTP, XMPP, IRC, then it's the most convenient thing to use
-- and therefore what the default implementation uses.
2. The design of the whole infrastructure is meant to be extensible
through the use of templates so in case any other protocol has
different requirements, as long as they rely on the message
abstraction and the message system, I'm confident it should be easy to
implement whatever specializations are required to get the desired
functionality on top of the existing design.

>
> I'll post my code later and we can discus approaches later.
>

It would be interesting to see your approach in code and see why you
think using std::string's (which are perfectly fine on their own by
the way able to hold binary data) is a bad thing.

> Thank you for your kind time,

No problem. Looking forward to your code to see what exactly the
problem with using std::strings in binary protocols are.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.