Re: [cpp-netlib-devel] URI

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

On Tue, Jan 19, 2010 at 11:29 PM, Jeroen Habraken <vex...@gm...> wrote:
>
> On Tue, Jan 19, 2010 at 15:51, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> When do you expect this to be available? I'm curious to see how that's
>> going to shape up granted that there's no more way to customize the
>> parsing of the specific parts.
>
> I've nearly got this working, so either today or tomorrow I hope.
>

Cool. :)

>>> - The parser doesn't have support for IP's yet, thus
>>> scheme://localhost/ works, scheme://127.0.0.1/ doesn't, whilst both
>>> are valid
>>
>> These were valid before IIRC and there must be tests to show that they
>> are supported.
>
> They are indeed valid, but I've not written the parser rules for them.
> I shall add a couple of tests reflecting this.
>

That would be great. :)

>>
>> I would better prefer that there be tests written first before any
>> work is done so that I can look at the tests and see whether the
>> feature to be added makes sense. The way I do it is I force test
>> failures first before I go write functionality.
>>
>> Please look up Test Driven Development and see if you can follow that
>> process instead. For one thing I will not commit a merge if tests are
>> failing.
>
> Yes, and I'm aware of TDD, but unfamiliar with Boost.Test. There are a
> couple of tests I've written outside the framework which need to be
> merged, for this I'll have to look into Boost.Test though (not that
> that's a bad thing).
>

Oh Boost.Test is sooooo easy compared to xUnit testing that it's even
a joke I even invested the time to learn the xUnit tests. Anyway I'm
looking forward to the tests. :)

>>
>> Alright, but I see that 'rest()' was removed too. The value of getting
>> the raw scheme-specific part of a URI is something I personally
>> require and prefer be still there.
>
> The newer RFC (http://www.ietf.org/rfc/rfc3986.txt) which deprecates
> RFC1738 has no notion of a scheme-specfic-part, which makes this
> rather hard. Could you please explain why you need it?
>

For logging purposes, it's more efficient to just get the stuff after
the ":". I guess it would be better if I log the raw string instead.

Since we're moving to the newer RFC then that should be alright. ;)

>> This is the main reason why I put that protocol()/scheme() and rest()
>> functions in the basic_uri type. The raw() accessor should also be
>> there so that a URI's raw string representation can be retrieved even
>> after the parts have been parsed already.
>
> I don't believe it was there initially, but it's trivial to add and makes sense.
>

Yes indeed. I've been meaning to do this but I haven't gotten around
to doing it. :)

>> Thanks for putting in the work and I hope this helps!
>>
>
> I know this is a rather large overhaul which influences the whole
> library, please bear with me and thank you for the response.
>

No worries, as long as it's not broken then it's something that's
worth the investment, it's definitely welcome. :)

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