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/
On Fri, Sep 21, 2012 at 11:15 AM, Glyn Matthews <glyn.matth...@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/
On Fri, Sep 21, 2012 at 7:15 PM, Glyn Matthews <glyn.matth...@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!
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.
> On Fri, Sep 21, 2012 at 11:15 AM, Glyn Matthews <glyn.matth...@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/
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?
On Fri, Sep 21, 2012 at 9:31 PM, Klaim - Joël Lamotte <mjkl...@gmail.com> wrote:
> 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?
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.
On Fri, Sep 21, 2012 at 1:36 PM, Dean Michael Berris <dber...@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:
On Fri, Sep 21, 2012 at 9:52 PM, Klaim - Joël Lamotte <mjkl...@gmail.com> wrote:
> On Fri, Sep 21, 2012 at 1:36 PM, Dean Michael Berris <dber...@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:
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/
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.
> 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.
