Re: [cpp-netlib-devel] Boost.CGI Merger (WAS RE: Nearly time tostart merging?)

[Darren G. <dar...@gm...>]

On 26/03/2008, Dean Michael C. Berris <dmb...@fr...> wrote:
>
> > -----Original Message-----
> > From: cpp...@li...
> > [mailto:cpp...@li...] On
> > Behalf Of Darren Garvey
>
> > Sent: Wednesday, March 26, 2008 4:12 AM
> > To: C++ Networking Library Developers Mailing List
>
> > Subject: Re: [cpp-netlib-devel] Boost.CGI Merger (WAS RE:
> > Nearly time tostart merging?)
>
>
> I'm not really sure if copying strings is really too inefficient
> compared to using iterator pairs. Although this may be 'premature
> optimization', it would be good to have at some point I guess.


You're right, I've vaguely benchmarked some of the CGI code and the
countless copies it does at the moment don't seem to impact *too* much. This
is probably something that should come in as and when benchmarking does (ie.
not yet).

> [snip]
> >
> >
> > I wasn't too sure about the as<> member function myself
> > either, but several people requested it and the idea already
> > has precedence in boost libraries, although I forget which
> > ones right now. Perhaps it would be better to have an
> > 'as<>-less' network::basic_param<> and then a
> > cgi::basic_param<> which derives from the former and adds the
> > as<> member function..?
> >
> > What do you think? *
> >
>
>
> I'd first like to see a use case for the basic_param<> idea -- as far as
> I see it in my head, a parameter is just a string. Although a string can
> be referred to with just a pair of iterators marking the beginning and
> the 'past end' position of a string of characters, I may need some
> convincing for the creation of a specialized type for iterator ranges.


Ok, I'll get back to you on this. TBH, I'm not entirely convinced of the
need for this myself. It keeps cropping up though so next time I feel
motivated I'll try and make a case! :)

Wouldn't a Boost.Range work with boost::lexical_cast<...>(...) ?


Hmm, not sure. It doesn't look like it to me - although it probably should
support it, no?

[snip]
>
> > This sounds like a good idea. For a readable basic_message<>
> > - ie. with the only addition being member functions
> > prepare/commit/consume - how about storage<basic_message<>> ?
> > This would allow direct reading/writing to/from the message with Asio.
>
>
> I'm not very familiar with the idea of 'storage<basic_message<> >', can
> you elaborate on that?


Sure. As I'm sure you're already aware, the Asio read/write functions only
deal with "(Mutable|Const)BufferSequence"s. boost::asio::basic_streambuf<>
provides some functions to read/write into/from it, which is what the
'storage<basic_message<>>' could mimic.

eg.
// untested
template<typename T>
class readable<basic_message<T>> : public basic_message<T>
{
public:
  typedef implementation_defined mutable_buffers_type;

  // get a mutable buffer that can be read into directly.
  mutable_buffers_type prepare(std::size_t size);

  // after reading, you call commit, marking how much data you read.
  void commit(std::size_t size);
};

template<typename T>
class writeable<basic_message<T>> : public basic_message<T>
{
public:
  typedef implementation_defined const_buffers_type;

  // get a const buffer that can be written directly.
  const_buffers_type data() const;
}:

template<typename T>
class readable_writeable<basic_message<T>> // or storage<basic_message<T>>
or whatever...
  : public readable<basic_message<T>>
  , public writeable<basic_message<T>>
{
};

Having these as adapters seems far more flexible to embedding extra member
functions into basic_message<>, I quite like this idea. In fact, the
readable_writeable<> class would probably drop right into the current CGI
codebase!

> Yeah, this is possible, but do you not think the
> > basic_message<> class should be as minimal as possible? In
> > the HTTP case you could possibly use something like:
> >
> > template<>
> > class basic_message<http::message_tag>
> >   : basic_message<tags::default_> // this might be wrong {
> >   std::string _source;
> >   std::string _destination;
> > public:
> >   std::string& source() const { return _source; }
> >   std::string& destination() const { return _destination; }
> > };
> >
> > We could then build up a message-type 'stack' on top of this
> > for the HTTP-based protocols and other 'stacks' for any other ones.
> >
>
> But this approach would break things because:
>
> basic_message<http::message_tag> http_message;
> basic_message<tags::default_> & message(http_message);
> message.source() = "Hello, World!";
> assert(http_message.source() == message.source()); // will fail


Yes, unfortunately it would. However, that makes me wonder what exactly a
'default message' is, or should be. An RFC822 Internet message? An RFC2616
HTTP message? I would prefer the former - ie. just a _header and  _body.
That way both HTTP parts and CGI parts could share a common base class.
AFAIK, specialising the basic_message<> class would mean duplicating code!

Sorry, I'm still somewhat confused as to the need for _source/_destination.
I might just be missing something. :(

The suggestion is to do something like:
>
> template <>
> struct basic_message<cgi::message_tag> {
>   ...
>   // copy constructor
>   template <typename Tag>
>   basic_message(basic_message<Tag> const & other)
>     :
>     _source(other.source()),
>     _destination(other.destination()),
>     ...
>     { };
>   ...
> };


It may seem very nit-picky, but I'd much rather avoid having to put a
superfluous source/destination parameter in each request object (the idea
would be that cgi::request, fcgi::request, etc. would all contain or derive
from basic_message<cgi::message_tag>). It's not that there would be much
performance impact - although it might show on a FastCGI daemon handling
thousands of requests - it just doesn't seem necessary.

> It all sounds very interesting. I wish I had some time to
> > start on it now!
>
> Don't we all? ;)


Hehe. I was really tempted to reapply for the GSoC along these lines -
getting the two libraries closer together and putting the CGI one up for
review. Hmm, I probably should have...

<snip>

Even so, parameterizing the allocator is another
> way to go about embedded system support. This is not one of the main
> concerns for designing the C++ Netlib _yet_, though if there's enough
> user demand for it and enough interest in making your
> phone/watch/stereo/tv/switch/router have an HTTP cilent/server, then
> that should be doable as well. :D


Yeah, this probably would be premature optimisation for the library at this
point. Anyway, I don't see why light switches shouldn't have their own
embedded servers! ;o)

Cheers,
Darren