Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

Hi Glyn!

On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <gly...@gm...> wrote:
> 2009/11/6 Glyn Matthews <gly...@gm...>
>
> You've defined new tags and traits classes in boost/network/uri/tags.hpp and
> boost/network/uri/traits/*  Why is this?  These are identical to those found
> in boost/network/message/tags.hpp and boost/network/message/traits/*.
> Surely they don't need to be repeated?
>

Oh, you're right. :) I didn't notice that. ;)

> Having said that though, I think the traits systems need to be extended,
> because your HTTP URI can't be specialized for std::wstring (or for any
> string which doesn't have an 8 bit character length).
>

Right...

> I would suggest something along the lines of:
>
> namespace boost {
> namespace network {
> template <
>     class Tag
>     >
> struct uri_traits {
>     typedef typename string<Tag>::type string_type;
>
>     typedef boost::uint32_t port_type;
>
>     static const string_type &colon() {
>         static const string_type colon = ":";
>         return colon;
>     }
>
>     static const string_type &qmark() {
>         static const string_type qmark = "?";
>         return qmark;
>     }
>
>     static const string_type &pound() {
>         static const string_type pound = "#";
>         return pound;
>     }
> };
>
>
> template <>
> struct uri_traits<tags::wdefault> {
>     typedef string<tags::wdefault>::type string_type;
>
>     typedef boost::uint32_t port_type;
>
>     static const string_type &colon() {
>         static const string_type colon = L":";
>         return colon;
>     }
>
>     static const string_type &qmark() {
>         static const string_type qmark = L"?";
>         return qmark;
>     }
>
>     static const string_type &pound() {
>         static const string_type pound = L"#";
>         return pound;
>     }
> };
> } // namespace network
> } // namespace boost
>
>
> Do you agree with this?  Unless I'm missing something, your spirit parser
> only needs to know a small number of special delimiting characters and the
> rest is generic because you then don't need to specify the string type
> internally.  I don't think this would easily extend to John's implementation
> though, but his code suffers from the same problem (it uses std::string a
> lot internally and isn't generic).
>

Yes, I like this. However, I don't want to glob the data into traits
classes. Let's come up with some other name that's dependent on the
tag, but is not called traits.

> Consequently, I'd like to see all your unit tests repeated for
> std::wstring.  I think this is important to do because it will really
> justify the approach we are taking.

I agree. Can this be done automatically? Copy-paste-replace?

>
> Is there a reason why you're providing the HTTP URI under
> boost/network/uri/http and not boost/network/protocols/http ?
>

Because I was thinking the URI library is something can be used
externally, it's feasible that we can package it as a separate library
to be downloaded and used in other packages. I don't mind moving it
though, it makes sense in either location. :D

> Otherwise I like the progress you're making, it is taking good shape.
>

Thanks!

> On another note, I'd like to get more involved with the development of the
> URI but I'm finding it difficult to know exactly where to join, since there
> are two completely different branches.  For one, I'd like to add the wstring
> unit tests I mentioned above (and actually some more for basic_message) but
> I don't know in what branch I should because your's and John's have diverged
> to a large extent.  I could do this either in trunk, or in integration_0_4
> but they might just end up being ignored.  In fact, this is a more general
> problem with the way we develop, I think, because it prevents other people
> from contributing code or tests or docs.  Any thoughts?
>

This bothers me a little too. I think we ought to merge the
implementations somewhere before merging to trunk -- I haven't been
following John's developments, but we can try and merge the tests
first, consolidate them so that we can use different implementations
underneath.

One thing that I like doing is to keep the design and implementation
as simple as possible -- and I really am not big on pre-design,
because the way I do it is that I try many different things and then
distill into an implementation that I like. I would love to make that
process more transparent and more "a-priori". Maybe we can do a skype
call and coordinate, I can better explain without doing any writing?

What I am open to is to try a merge of the tests first -- then let's
take approaches from one branch (from John's) and merge them into
another branch (uri?). If you can try and do this Glyn, and and have
everyone work on the same branch to stabilize the implementation, then
we can work on moving in the same direction.

How that that sound? (BTW, in Git this would be really "simple" to do. ;) )

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com