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

[K. G. <kim...@gm...>]

Hi Dean,

On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
<mik...@gm...> wrote:
>>
>> I created a branch succinctly called 'uri', on
>> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri
>>
>> I've committed the first fumbling parts there, in
>> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp.
>>
>
> Quick question: where did you branch from? trunk or http_integration?

>From trunk.

>> I didn't parameterize the string type mainly because the default tag
>> is under network/protocol/http, and the URI goes one level up in the
>> hierarchy, but I suppose I could introduce a temporary tag to wrap the
>> string typedef.
>
> That raises a good issue though: should we have a single place to have
> the tags hierarchy depicted?
>
> I'm thinking:
>
> namespace network {
>  struct tags {
>    struct http {
>      struct message {
>        struct tag { };
>      };
>      // ...
>    };
>    struct message {
>      struct tag { };
>    };
>    // ...
>  };
> }

It feels a little strange pushing the tags together, but I can't say
why, really... It creates sort of a hotspot, where everybody will have
to make edits in order to add new protocols, etc. That's probably not
a huge problem.

> That way we can build traits on top of this hierarchy under a
> different namespace 'traits':
>
> namespace network { namespace traits {
>  template <class Tag> string;
>  template <class Tag> buffer;
>  template <class Tag> ostringstream;
>  template <class Tag> char_;
>  // ...
> } }

I think it makes sense to keep the traits together, there's bound to
be a lot of overlap (especially around strings).

> And specialize them as necessary as well?

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

- Kim