|
From: Michael D. <mi...@mi...> - 2008-04-06 17:53:46
|
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 |