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

[Michael D. <mi...@mi...>]

On Mar 24, 2008, at 8:53 PM, Dean Michael C. Berris wrote:
>

>> ...
>> This does raise the question though of whether or not an
>> http_message<> class would make sense?  i.e.
>>
>> http::message<> : public basic_message<>;   (or http_message<>?)
>> http::request<> : public http::message<>;
>> http::response<> : public http::message<>;
>>
>> Perhaps this makes more sense as we add more members to the http
>> message objects...?
>>
>
> The hierarchy depicted above makes logical sense to me -- unless  
> there's
> opposition to the inheritance hierarchy above, I say go for it.
>
> On the issue of 'http_message', it would be perfectly fine for
> http::message<> to contain structural information that's unique to  
> that
> type without it having its own base separate from the basic_message<>.
> So I personally don't see the need for a different message type that's
> not derived from basic_message<> because after all, the intention of  
> the
> basic_message<> is to provide a common base for all messages to be
> defined from.
> ...

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)?

...
>> As for using an "unordered" container, that is my personal
>> preference
>> and what we are using in pion-net.  The challenge with this is with
>> compiler support; not everyone seems to support tr1 yet, but those
>> which do not support alternatives (i.e. stdext::hash_map in
>> gcc).  We
>> have a separate "PionHashMap.hpp" header in pion that uses #define's
>> to work-around the compiler differences.
>>
>> I left it as a "multimap" in my code for the sole purpose of
>> starting
>> out keeping everything as simple as possible.  I do like the idea of
>> hashing for these headers, though since this would (in theory) help
>> increase the performance of lookups (of course, in practical use it
>> might make no difference..)  If you prefer that route too, I can
>> convert over the #define stuff we have in PionHashMap, maybe
>> by adding
>> a "unordered_map.hpp" details file?
>>
>
> I like unordered too, but I usually have not found a compelling case  
> for
> something like that except in performance critical code. Though in  
> this
> case, it might be a good decision to make early in the game. ;)

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.

> 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?

>>>> ...
>> Interesting.. so we could leave it up to the user to define the
>> container type for these (i.e. multimap or unordered_multimap)?
>>
>> Sort of makes me wonder though if we'd be giving people too
>> much rope
>> (to hang themselves with)?  Versus making it a specific type, that's
>> protected and only allows accessors?
>>
>
> Not really the users -- more like people who want to extend the  
> library.
> Remember that we will be implementing 'query_params<>' and
> 'cookie_params<>' for the tags we define. If for some reason people
> would want to extend or modify the functionality of the request  
> objects,
> then it should be entirely possible in the most un-intrusive manner.

Got it =)

...
>>> Guess I need to read up on the fusion library =)
>>
>> Would this just be for container types or does it apply to simple
>> types (like ints) as well?
>>
>
> A fusion map works like this:
> ...
> So what the fusion map allows you to do is to map values to types, so
> that you can index the values using types instead of relying on some
> form of polymorphism at runtime. Of course, you could do it with  
> member
> variables but that takes away the capability to perform compile-time
> munging/processing on the encapsulated data in the fusion container  
> (in
> this case, a fusion map).

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

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..

Take care,
-Mike