Re: [cpp-netlib-devel] New Branch on Github

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

On Tue, Dec 15, 2009 at 3:26 AM, Jeroen Habraken <vex...@gm...> wrote:
> On Mon, Dec 14, 2009 at 17:45, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> I'd say a function that interprets the query part doesn't have to be
>> part of the uri interface. I'd accept a function which would parse out
>> the the .query() part of the uri into a
>> list<pair<string_type,string_type> > that looks like this:
>>
>>  list<pair<string,string> > query_list_ = query_list(uri);
>>
>> This should be available via ADL and only for http uri's. The
>> simplicity of the HttpUri concept should be preserved. Also, I'd
>> imagine the query_list(...) function to dispatch to a specific
>> implementation based on the tag associated with the uri. This is so
>> that we can change the result type based on the tag associated with
>> the uri too, so for example instead of a list<pair<string,string> > we
>> can return a generator function, an input iterator, a
>> multimap<string,string>, or a tuple.
>
> This is indeed a better option, it keeps the URI parser relatively
> simpler and prevents unnecessary work, whilst we still provide this
> functionality, consider it on my TODO list.
>

Cool. :)

>>
>> I don't understand what the concern is. Is there a problem you're
>> seeing with the current approach?
>
> I should have been more clear here, normally when URI decoding a
> string quite a few things can go wrong, imagine incorrect characters
> '%2S', or it simply being too short, '%2'. A URI will not be parsed as
> valid if such cases occur, making URI decoding relatively trivial as
> you won't have to deal with such cases. We should provide a fully
> functional uri_decode function though, capable of handling any input.
> There actually turns out to be a fine implementation in the Boost.Asio
> examples already, it's in
> libs/asio/example/http/server/request_handler.cpp as url_decode.
>

Right, but that is the reason why the query part of the parser was
very lax was that it should be externally dealt with through different
functions. Although the validity check as far as RFC strictness is
concerned is good, decoding the URI elements should be secondary to
the role of the parser which is supposed to just identify which part
of the URI is what.

I have been looking for a way of easily encoding and decoding URI's
with Boost.Spirit's Qi and Karma libraries. Maybe one day when I find
the need for that functionality I'll write it -- or if you want to
take on that implementation, then it should be something you can take
on as well. :D

>> Also, please modify the patch to include your copyright information at
>> the top of the files you modify. :)
>>
>> Thanks again!
>
> You're most welcome. I've just created a github account, and think
> forking the master and working from there is the easiest option.
>

Indeed. :)

Have a great day and week ahead!

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