Hi Glyn!
On Mon, Nov 9, 2009 at 5:21 AM, Glyn Matthews <[email protected]> wrote:
>
>
> 2009/11/8 Dean Michael Berris <[email protected]>
>>
[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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Cpp-netlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
