Developments for the URI

[Glyn Matthews]

Hi all,

As some progress has been made on other parts of the library recently, I will share with you some developments that I have made.

First, I have developed a preliminary proposal to the C++ standards committee for the addition of URI class to the standard library, based on the URI in cpp-netlib. The proposal document is available here: http://glynos.github.com/uri_proposal/

Second, I will deliver a presentation on cpp-netlib to the Belgian C++ UG in Brussels in October. If you are interested in attending, more information can be found here: http://becpp.org/blog/2012/09/03/next-becpp-ug-meeting-planned-for-october-16th/

Glyn

[Klaim - Joël Lamotte]

On Fri, Sep 21, 2012 at 11:15 AM, Glyn Matthews <glyn.m...@gmail.com> wrote:

First, I have developed a preliminary proposal to the C++ standards committee for the addition of URI class to the standard library, based on the URI in cpp-netlib. The proposal document is available here: http://glynos.github.com/uri_proposal/

Ohh intersting! Will read!

 

Second, I will deliver a presentation on cpp-netlib to the Belgian C++ UG in Brussels in October. If you are interested in attending, more information can be found here: http://becpp.org/blog/2012/09/03/next-becpp-ug-meeting-planned-for-october-16th/

I should not be that far from it, I'm in Lille (France)  but I'm not sure I will be able to get there. I'll try.

Joel Lamotte

[Dean Michael Berris]

On Fri, Sep 21, 2012 at 7:15 PM, Glyn Matthews <glyn.m...@gmail.com> wrote:
> Hi all,
>
>
> As some progress has been made on other parts of the library recently, I
> will share with you some developments that I have made.
>
> First, I have developed a preliminary proposal to the C++ standards
> committee for the addition of URI class to the standard library, based on
> the URI in cpp-netlib. The proposal document is available here:
> http://glynos.github.com/uri_proposal/
>

Thanks for doing this Glyn! Glad we're able to contribute to the C++
standard even though the project is still pretty small. Hopefully
we'll get more people to get involved in the process soon because of
this!

> Second, I will deliver a presentation on cpp-netlib to the Belgian C++ UG in
> Brussels in October. If you are interested in attending, more information
> can be found here:
> http://becpp.org/blog/2012/09/03/next-becpp-ug-meeting-planned-for-october-16th/
>

If you're going to be near there, I highly suggest you go see Glyn
give this talk. I'd love to get feedback on how this goes too so we
can gather feedback from the ground!

Thanks for doing this too Glyn, definitely much appreciated.

Cheers


--
Dean Michael Berris | Software Engineer
Google

[Dean Michael Berris]

I certainly hope you can make it there and meet Glyn in person! :)

[Klaim - Joël Lamotte]

I have a question, 

Why is it necessary to have that builder class? Is there a fundamental problem if solves or could it be possible to allow building an uri by member functions?

Joel Lamotte

[Dean Michael Berris]

I think Glyn points out in the paper that the builder is a convenience
that can be specialized to do the encoding and/or sanity checking.

One use that's not obvious is re-usability when creating URI instances. Example:

uri::builder google;
google.scheme("http").host("www.google.com");
uri search = google.path("search");
uri help = google.path("help");

Or something similar.

Imagine having to do that all repetitively for multiple domains.

Hope this makes sense. :)

[Klaim - Joël Lamotte]

On Fri, Sep 21, 2012 at 1:36 PM, Dean Michael Berris <dbe...@google.com> wrote:

Imagine having to do that all repetitively for multiple domains.

Hope this makes sense. :)

Partially. Do you mean, you want to be able to keep the paths and other data in the builder, but change one like the domain and generate new uri with it?

On another related note: It is not clear to me if the URI standard allows ':' in the path, like this:

myprotocol://my.domain.com/foo:bar/something:special/

I suppose it is not allowed but it's not clear. 

Last question: does the current network::uri class match all that is presented in the documentation or not yet?

Joel Lamotte

[Dean Michael Berris]

On Fri, Sep 21, 2012 at 9:52 PM, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:
>
>
> On Fri, Sep 21, 2012 at 1:36 PM, Dean Michael Berris <dbe...@google.com>
> wrote:
>>
>>
>> Imagine having to do that all repetitively for multiple domains.
>>
>> Hope this makes sense. :)
>
>
> Partially. Do you mean, you want to be able to keep the paths and other data
> in the builder, but change one like the domain and generate new uri with it?
>
>

Yes, that's the idea and original motivation for having it in the
first place. :)

>
> On another related note: It is not clear to me if the URI standard allows
> ':' in the path, like this:
>
> myprotocol://my.domain.com/foo:bar/something:special/
>
> I suppose it is not allowed but it's not clear.
>

I'll defer to Glyn (or Jeroen) who knows the RFC a little more deeply than I do.

> Last question: does the current network::uri class match all that is
> presented in the documentation or not yet?
>

Not yet. :) That's the point of the re-write that's coming. :D

[Glyn Matthews]

Hi Martin,

On 18 November 2012 07:37, Martin Gentry <imagin...@gmail.com> wrote:

On Friday, September 21, 2012 5:15:21 AM UTC-4, Glyn Matthews wrote:

Hi all,

As some progress has been made on other parts of the library recently, I will share with you some developments that I have made.

First, I have developed a preliminary proposal to the C++ standards committee for the addition of URI class to the standard library, based on the URI in cpp-netlib. The proposal document is available here: http://glynos.github.com/uri_proposal/

I happened across this while looking browsing every manner of thing on the new isocpp.org site and since networking is an interest of mine I eventually landed at http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3484.html.

First, it's awesome to see a proposal along these lines for standardization!

Second, I have a question about something that sort of jumped out at me.

The example usage includes the following:

assert(uri.query().string() == "?key=value");

assert(uri.fragment().string() == "frag");

Why does the expected value from query() contain the '?' prefix, but fragment() doesn't include the '#' prefix? I'd be inclined to prefer both exclude the initial prefix, but I am curious what the motivation was for the apparently inconsistency? More so since it seems the current uri implementation in cpp-netlib excludes the prefix in both cases.

 

OK, I acknowledge this is a mistake I made in the proposal. I have already raised this on the reflector where the proposal is being discussed.

Many thanks,

Glyn