Re: [cpp-netlib-devel] HTTP Code Conversion (WAS RE: A fewquestions)

[Dean M. C. B. <dmb...@fr...>]

> -----Original Message-----
> From: cpp...@li... 
> [mailto:cpp...@li...] On 
> Behalf Of Michael Dickey
> Sent: Monday, April 07, 2008 1:54 AM
> To: C++ Networking Library Developers Mailing List
> Subject: Re: [cpp-netlib-devel] HTTP Code Conversion (WAS RE: 
> A fewquestions)
> 
[snip]
> 
> I just added a new message.hpp file that includes a 
> http::message base class, which both http::request and 
> http::response now derive from.  Do you think just 
> "http::message" works best or might this be confusing with 
> "basic_message" (since in the code the "http" namespace is 
> not explicitly qualified)?
> 

I'll check it out and see how exactly it looks like before providing
comments. One thing that came to mind was that "http::message" can just
be "basic_message<http::message_tag>" -- which can be defined as an
explicit specialization of the basic_message type. I'll look at the
implementation and I might try this idea out some time.

> 
> I was doing some performance tests & comparisons recently for 
> other reasons, and I think I disproved my assumption that 
> unordered containers are faster.  If you're doing lots of 
> lookups and the objects have long lifetimes, then I believe 
> they would be faster than ordered containers.  However, with 
> short-lived containers that do not perform lots of lookups, 
> the plain old multimap is several times faster.  I believe 
> that this is due to the overhead required to create and 
> destroy the hash tables.
> 
> So, in retrospect, I now believe that sticking with map and 
> multimap is our best bet for http objects.
> 

Sounds good to me. :)

> 
> 	I have a comment though on the 'types' namespace -- 
> would you think this
> 	would be unneccessary? I don't see a problem with having an
> 	'http::headers' struct which contained all the 
> necessary strings.
> 	Example would be something like:
> 	
> 	namespace http {
> 	 template <typename Tag=tags::default_tag>
> 	   struct headers_impl {
> 	     static char const * const CONTENT_LENGTH = 
> "Content-length";
> 	     ...
> 	   };
> 	
> 	 typedef headers_impl<> headers;
> 	}
> 	
> 	If it wouldn't be too much of a pain to use unordered 
> containers inside
> 	the basic_message<http::message_tag> and maintain a 
> consistent interface
> 	that the basic_message<> exposes (and some more unique to the
> 	basic_message<http::message_tag>) then I'd say go ahead 
> with that
> 	approach instead.
> 
> 
> I've nuked the old types files & struct.  Still a little 
> uncertain on the best naming and location.  "headers" didn't 
> really feel right to me since it also includes other 
> container types, status codes and such.  For now, I moved the 
> static functions into the new http::message base class, and 
> created a new traits.hpp file that contains all the constants 
> and data types for http messages and the http parser in new 
> message_traits<> and parser_traits<> structs.  This seems 
> like the most logical structure for now, unless you have a 
> better suggestion?
> 

What we can do is organize the contants into appropriately named wrapper
types. We can even group them with the use of traits classes. Before
going further, I can give an example here:

  namespace http { namespace constants {
    template <typename Tag = message_tag>
      struct status {
        enum { OK = 200, ... };
      };

    template <typename Tag = message_tag>
      struct mime_type {
        static char * const text_plain = "text/plain";
        static char * const text_html = "text/html";
        ...
      };
  }; // namespace constants

  }; // namespace http

I don't particularly like 'constants' because it's long and too verbose,
but I hope this brings the point across more clearly. ;)

> 
> Next thing on my list will be reading the fusion docs & 
> starting to merge over code into the http::request & 
> http::response objects...
> 

Believe me, if you've ever tried doing any sort of Boost.MPL munging
around, Boost.Fusion brings the 'higher level MPL voodoo' closer to
runtime where (most of the time) it matters most. :) But don't take my
word for it, you should try Fusion out and see for yourself. :)

> Once I have a better grasp of things and get these core http 
> classes in place, I think that converting the rest of the 
> code should move fairly smoothly..
> 

Sounds good to me. :) I'll update my working copy and look at the
http::message -- I'll write more about what I think about it later. :)

--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459