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

[Glyn M. <gly...@gm...>]

Hi,

2008/10/13 Kim Gräsman <kim...@gm...>

> On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
> > 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.
>

It could be a problem.  I share your concern about this.  But I don't know a
solution to this yet.


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



right.  But I think it might be better named:
namespace network { namespace traits {
template <class Tag> string_type;
template <class Tag> buffer_type;
template <class Tag> ostringstream_type;
template <class Tag> char_type;
}}

On an unrelated note, doesn't using ostringstream always require
basic_string?  And char_type is not orthogonal to string_type and char_type.


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


I'm not sure what you mean here.  Can you elaborate?

Glyn