|
From: Dean M. C. B. <dmb...@fr...> - 2008-04-15 10:46:22
|
Hi Everyone,
I took some time out to look at the implementation of the http::message
-- and right off the bat I see a few issues.
- I don't see unit test(s) for the implementation(s). I know that this
code has been adapted from an already existing library, and it would be
nice to see it in action first even in a measy unit test. I'll try
working on some later just to verify the implementation of the
http::message. Mike, can you give me (or everyone for that matter) an
idea as to how we should be using the http::message in particular
independent of the client? I can write some unit tests to check if it
still complies with the basic_message<> interface. Please let me know if
you want me to do this.
- I don't particularly like 'parser_traits' because it gives me the idea
that it contains nested types instead of constants. I don't have any
better suggestion than 'parser_constants', but somehow we need to
resolve this naming issue one way or another.
- I was suggesting earlier to have instead a tag type which
differentiated an http::message from a basic_message, because precisely
to avoid the glob traits facility that we see in message_traits (and
like the standard iterator traits that glob values together). The
approach would be similar to:
namespace http { namespace tags {
struct message_tag { };
}; };
namespace http { namespace traits {
template <typename Tag>
struct delimiters;
template <>
struct delimiters<tags::message_tag> {
static char const * const STRING_CRLF =
"\x0D\x0A";
...
};
template <typename Tag>
struct header_names;
template <>
struct header<tags::message_tag> {
static char const * const HEADER_HOST = "Host";
};
}; };
In the above approach, we can then even support wide character strings,
by using a different tag to support wide characters.
namespace http {
namespace tags {
struct message_tag_w { };
};
namespace traits {
template <> struct
delimiters<tags::message_tag_w> {
static wchar_t const * const CRLF =
L"\x0D\x0A";
...
};
};
};
The technique is almost like tag dispatching for methods, only this time
it's tag dispatching for type traits.
I can help with this conversion if there are no objections.
Mike, do you see a problem with libpion if we do it the way above?
- If we go with the tag dispatching approach, we can then have a
specialization on basic_message<> instead that has structural details
unique to that specialization.
Please let me know what you think guys, it looks like I'll be going to
need this _real soon_ so I now have a personal stake at making sure this
goes through as planned. ;)
--
Dean Michael Berris
Software Engineer, Friendster, Inc.
<dmb...@fr...>
+639287291459
|