Re: [cpp-netlib-devel] URI status

[Jeroen H. <vex...@gm...>]

On Sat, Jan 9, 2010 at 07:59, Dean Michael Berris
<mik...@gm...> wrote:
> On Sat, Jan 9, 2010 at 8:16 AM, Jeroen Habraken <vex...@gm...> wrote:
>> Hi guys,
>>
>> It's been a while since you've heard from me, and first of all -though
>> somewhat late- a Happy New Year.
>
> Happy New Year to you too! :)
>
>> I've been reading up on the RFC and
>> Spirit documentation (Spirit is pure genius by the way). I'm now
>> working towards a full RFC compatible parser[1]. In doing so I've
>> found the newer RFC3986 is much more of a pleasure to work with, and
>> the specific HTTP parser isn't needed any more.
>>
>
> Okay, I hope you realize that the URI's are not just going to be for
> HTTP, and that we do want support FTP, SMTP, and other protocols. I
> don't see how you can do this without the specific parser dispatched
> by tag.
>

Yes, what I meant, the new generic parser will actually do this all
correctly, it now knows the difference between scheme://.. and
scheme:.. and things like that, thus the new derived objects will only
have to do checks like "Is the scheme actually 'http'", it won't have
to do any more specific parsing.

>> I've noticed a couple of things though, and I'm uncertain on how to
>> solve them. First of all, ports, there is the difference between the
>> parsed port, and the actual port to use when connecting, based on
>> default ports. The google-url has a port and EffectiveIntPort
>> function, but this information is also needed when normalising the
>> URI. Secondly, the parser knows the difference between no fragment,
>> and an empty fragment, but the current API does not expose this. Would
>> exposing the optional<string_type>'s be a solution?
>>
>
> I'd like the optional to be exposed too, that's a good idea. I've been
> thinking about it for a while already and I remember having that as
> one of the things to change.
>
> If you want to change that and the tests to reflect the new interface
> exposing the optional<>'s then that would be great. :)
>

Great, I'll change them to reflect that.

>> Jeroen Habraken
>>
>> [1] This is currently not committed to git yet, I have still to
>> properly figure out GitHub, and fork the right branch
>>
>
> Actually, you can continue working on your fork and just ask me to
> pull when you feel like it's all fine. The fork is basically your
> branch from master that you maintain.
>
> I for one will keep continuing to work with 0.5-devel to implement the
> other tags and other client types in time for release by the end of
> the month. If you look at the latest (which you should rebase to) in
> master, it would show that I've merged the HTTP Server and HTTP 1.1
> Client with chunked encoding support (as well as HTTPS).
>
> If you're familiar with Git already, then think of your fork as just
> another repository. Nothing special, you can do whatever you want with
> your repository. Once you're done making changes in your repository
> and want to have me integrate your changes to be the "official"
> release, then you send me a pull request from your master branch --
> I'll take care of the merging to cpp-netlib.
>
> HTH
>
> --
> Dean Michael Berris
> cplusplus-soup.com | twitter.com/deanberris
> linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
>

Great, I think I'll make a new fork, specifically off the 0.5-devel
branch so things won't have to be merged with the master until
necessary.

Jeroen