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

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

Hi Glyn!

On Mon, Nov 9, 2009 at 5:21 AM, Glyn Matthews <gly...@gm...> wrote:
>
>
> 2009/11/8 Dean Michael Berris <mik...@gm...>
>>
[snip]
>>
>> 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?
>

I would want to move them into one class each -- that way in case we
need to add more 'constants' we don't change a globbed together class
that easily grows and becomes unweildy -- also, it also allows us to
re-use these in other contexts. It doesn't hurt to have them
individually in different classes either, except maybe the duplication
of opening and closing braces. ;)

I would make a namespace which contains the delimiters, something like
'boost::network::uri::detail::delimeters' and have each class named
appropriately like 'detail::delimeters::colon<Tag>::char_()' or
'detail::delimeters::question_mark<Tag>::char_()'.

For the first try though if you'd like to implement it with a single
'delimeters' type with a tag and then call the static functions by
name like 'detail::delimeters<Tag>::question_mark()', please be my
guest. Changing later on should not be a problem since it's an
implementation detail. ;)

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

I agree. Would you make it happen and let me know so that I can pull
your changes? :D

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

Yeah, I guess. Feel free to move them around -- also let me know when
it's done so that I can pull your changes. :D

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

Sounds great Glyn, thanks for taking this on!

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