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

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

2009/11/8 Dean Michael Berris <mik...@gm...>

> Hi Glyn!
>
> On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <gly...@gm...>
> wrote:
> > 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.
>
>

Are you suggesting each delimiting string be in it's own class,  or just a
rename of the uri_traits class?  I never intended it to be a glob, but
uri_traits is certainly the wrong name.  What about uri_delimiters?

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

I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
original tests so that they use template member functions:

BOOST_AUTO_TEST_CASE(my_uri_test) {
    boost::network::basic_uri<tags::default_> instance;
    my_uri_test_impl(instance);
}

BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
    boost::network::basic_uri<tags::wstring> instance;
    my_uri_test_impl(instance);
}

or something like that, it won't be difficult.  But looking at that, we'll
need better names for the tags.

>
> >
> > 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
>
>
Perhaps, but as a header-only library, does this matter?  As long as the
headers don't pull in unnecessary dependencies, I think it's better to keep
them grouped by protocol.  I think this will be much clearer when we add
more protocols.


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

Perhaps, but the change to Git probably shouldn't happen midway through a
development cycle.  I will continue to use integration_0_4, and I'll merge
your's and John's tests.  I'll try and find time to do that this coming
week.


Glyn