Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

[Dean M. B. <mik...@gm...>]

On Mon, Oct 13, 2008 at 7:58 PM, Kim Gräsman <kim...@gm...> wrote:
> HI Glyn,
>
> On Mon, Oct 13, 2008 at 11:47, Glyn Matthews <gly...@gm...> wrote:
>>
>>> Most of the specializations are useful on a global level, but at the
>>> same time it would be nice to keep the specializations close to the
>>> code that uses them, rather than listing unrelated but similar specs
>>> (string<message_tag>, string<uri_tag>) one after another.
>>>
>>> I don't have any good suggestions... Is there a way of reusing
>>> tag/traits definitions, so that one can create a 'base' definition
>>> with the string stuff, and then 'derive' and add more
>>> protocol-specific definitions? I'm just thinking out loud...
>>
>> I'm not sure what you mean here.  Can you elaborate?
>
> Sure, I'll try.
>
> If we look at this specific example, where we've added basic_uri, it
> doesn't share tag with basic_message (default_tags vs.
> tags::default_).
>

Why not use tags::default_ like basic_message?

> So with every template that needs a new tag, but shares traits with
> existing classes/templates (typically string, ostringstream, char_),
> we have to duplicate these definitions.
>

Do you really need a new tag?

> That's why I was wondering if there's a mechanism to reuse the traits
> between different tags.
>

I don't think there's a need for a different tag if you intend to work
with the default tag, which is already defined in the library.

Unless you want another point of customization, in which case it's
better to just re-use the existing default_ tag.

The reason we have a http::message_tag is because there are traits
supported by http::message_tag that don't support the default_ tag.
It's also a point of customization intended for extension -- so if you
want a different storage mechanism for HTTP Messages (like unordered
multi-maps for headers, etc.) then you create your own tag and
specialize the traits you want to support explicitly.

I don't see a need for a basic_uri template to define it's own tag
different from the default_ tag especially if you just intend to
re-use the same traits used for the message traits.

I'd even think we should promote the traits for the message class to a
higher traits namespace, to be (re)used throughout the project. ;-)

> Does that even make sense? :)

I think I'm still missing details as to why you need a separate tag
apart from the default_ tag that's already available.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.