Re: A URL API

[Adam Barth]

On Tue, Dec 7, 2010 at 1:17 PM, Jonas Sicking  wrote:
> On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
>> On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
>>> On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher  wrote:
 On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
 wrote:
> That sounds good to me. In general I think it would be great if there were
> standard APIs for URI/IRI construction, parsing and resolution...

 Yes, that sounds pretty good to me too.
>>>
>>> This has annoyed me for a while too.  I'll write up a spec.
>>
>> Here's a sketch:
>>
>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>
> It appears [1] that there are sites out there which use URL as a
> property already, which isn't very surprising.
>
> The good news is that if we ensure that the property is replacable
> then it seems like things will work. So all that should be needed is
> the right WebIDL magic, or right prose, to define that the URL
> property is replaceable.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=617296

Done.

Adam

Re: A URL API

[Jonas Sicking]

On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
> On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
>> On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher  wrote:
>>> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
>>> wrote:
 That sounds good to me. In general I think it would be great if there were
 standard APIs for URI/IRI construction, parsing and resolution...
>>>
>>> Yes, that sounds pretty good to me too.
>>
>> This has annoyed me for a while too.  I'll write up a spec.
>
> Here's a sketch:
>
> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en

It appears [1] that there are sites out there which use URL as a
property already, which isn't very surprising.

The good news is that if we ensure that the property is replacable
then it seems like things will work. So all that should be needed is
the right WebIDL magic, or right prose, to define that the URL
property is replaceable.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=617296

/ Jonas

Re: A URL API

[timeless]

On Mon, Sep 20, 2010 at 9:27 AM, Adam Barth  wrote:
> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe  
> wrote:
>>> 1) There are now two methods for getting at the URL parameters.  The
>>
>> and none for setting them?
>
> That's correct.  Looking at various libraries, there seems to be much
> more interested in paring out query parameters than for constructing
> them.  One popular JavaScript library did have an API that took a
> dictionary and built a query string out of it.  I imagine most folks
> just use the HTML Form element.

MXR (hg.mozilla.org/webtools/mxr/) has an api for constructing urls
(mostly parameters really). It tends to do redirects/rewrites which
send most but not all of a set of parameters to another location.
Another thing it sometimes tries to do is drop empty bits () from the url. another thing it of course does is
strip out '../' or similar variations.

Note that MXR happens to mostly do its work server side, but there are
bits which would do equivalent work client side, the server/client
side bit is an implementation detail and I'd expect that people not
caring about JS-off browsers would put much more of the code into the
client and use javascript to do these manipulations.

I'm sorry that I don't have time to read the current document. I'll
try to do that once I finish reading my backlog.

Re: A URL API

[Tab Atkins Jr.]

On Wed, Sep 22, 2010 at 12:54 AM, Devdatta Akhawe  wrote:
>> 2) I've added two flavors of appendParameter.  The first flavor takes
>> a DOMString for a value and appends a single parameter.  The second
>> flavor takes an array of DOMStrings and appends one parameter for each
>> array.  This seemed better than using a variable number of arguments.
>
> -1
>
> I really want the setParameter method - appendParameter now requires
> the developer to know what someone might have done in the past with
> the URL object. this can be a cause of trouble as the web application
> might do something that the developer doesn't expect , so I
> specifically want the developer to opt-in to using appendParameters.

If you really don't want to care what happened before, either do a
clearParameter every time first, or define your own setParameter that
just clears then appends.  Append/clear is a cleaner API design in
general imo, precisely because you don't have to worry about colliding
with previous activity by default.  A set/clear pair means that you
have to explicitly check for existing data and handle it in a way that
isn't completely trivial.

> I know clearParameter is a method - but this is not the clear
> separation between the '2 APIs' that we talked about earlier in the
> thread.
>
> I remember reading about how some web application frameworks combine
> ?q=a&q=b to q=ab at the server side, whereas some will only consider
> q=a and some will only consider q=b. This is such a mess - the
> developer should have to specifically opt-in to this.

It's a mess for server-side languages/frameworks, yes.  Some of them
handle this incorrectly.  Most of the current crop of popular ones,
though, do things properly with one method that retrieves the last
value and one that retrieves all values (PHP is marginal in this
respect with its magic naming convention).

Attempting to relegate same-name params to second-tier status isn't a
good idea.  It's very useful for far more than the "old services that
are also accessed via basic HTML forms" that you stated earlier.

~TJ

Re: A URL API

[Devdatta Akhawe]

> If you really don't want to care what happened before, either do a
> clearParameter every time first, or define your own setParameter that
> just clears then appends.  Append/clear is a cleaner API design in
> general imo, precisely because you don't have to worry about colliding
> with previous activity by default.  A set/clear pair means that you
> have to explicitly check for existing data and handle it in a way that
> isn't completely trivial.

I am not saying remove append - I am saying that just also have set,
with the semantics that if you use set, its equivalent to clear;append

> Attempting to relegate same-name params to second-tier status isn't a
> good idea.  It's very useful for far more than the "old services that
> are also accessed via basic HTML forms" that you stated earlier.
>

I am not sure about that - I think a modern API design would be to
just send multiple values as an array (maybe CSV or TSV). Consider how
JSON values are encoded - do you have multiple values to denote
arrays? neither is this the case in XML (afaik). This semantic of
multiple yet different values for the same parameter is just
confusing, and as you said a mess for server side. I am less
optimistic than you are that it will be fixed.

cheers
devdtta


> ~TJ
>

Re: A URL API

[Adam Barth]

Thanks for all your input.

1) I've renamed getParameterByName to getParameter and
getAllParametersByName to getParameterAll.
2) I've added two flavors of appendParameter.  The first flavor takes
a DOMString for a value and appends a single parameter.  The second
flavor takes an array of DOMStrings and appends one parameter for each
array.  This seemed better than using a variable number of arguments.
3) I've added a clearParameter method.

Defining these methods required some low-level URL manipulation that's
not actually defined anywhere (AFAIK), so I've added a reference to my
work-in-progress draft about parsing and canonicalizing URLs.

Adam


On Tue, Sep 21, 2010 at 3:40 PM, Ojan Vafai  wrote:
> appendParameter/clearParameter seems fine to me.
> On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. 
> wrote:
>>
>> On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth  wrote:
>> > Ok.  I'm sold on having an API for constructing query parameters.
>> > Thoughts on what it should look like?  Here's what jQuery does:
>> >
>> > http://api.jquery.com/jQuery.get/
>> >
>> > Essentially, you supply a JSON object containing the parameters.  They
>> > also have some magical syntax for specifying multiple instances of the
>> > same parameter name.  I like the easy of supplying a JSON object, but
>> > I'm not in love with the magical syntax.  An alternative is to use two
>> > APIs, like we current have for reading the parameter values.
>>
>> jQuery's syntax isn't magical - the example they give using the query
>> param name of 'choices[]' is doing that because PHP requires a [] at
>> the end of the query param name to signal it that you want multiple
>> values.  It's opaque, though - you could just as easily have left off
>> the '[]' and it would have worked the same.
>>
>> The switch is just whether you pass an array or a string (maybe they
>> support numbers too?).
>>
>> I recommend the method be called append*, so you can use it both for
>> first sets and later additions (this is particularly useful if you're
>> just looping through some data).  This obviously would then need a
>> clear functionality as well.
>>
>> ~TJ
>>
>
>

Re: A URL API

[Devdatta Akhawe]

> 2) I've added two flavors of appendParameter.  The first flavor takes
> a DOMString for a value and appends a single parameter.  The second
> flavor takes an array of DOMStrings and appends one parameter for each
> array.  This seemed better than using a variable number of arguments.

-1

I really want the setParameter method - appendParameter now requires
the developer to know what someone might have done in the past with
the URL object. this can be a cause of trouble as the web application
might do something that the developer doesn't expect , so I
specifically want the developer to opt-in to using appendParameters.

I know clearParameter is a method - but this is not the clear
separation between the '2 APIs' that we talked about earlier in the
thread.

I remember reading about how some web application frameworks combine
?q=a&q=b to q=ab at the server side, whereas some will only consider
q=a and some will only consider q=b. This is such a mess - the
developer should have to specifically opt-in to this.

cheers
devdatta


> 3) I've added a clearParameter method.
>
> Defining these methods required some low-level URL manipulation that's
> not actually defined anywhere (AFAIK), so I've added a reference to my
> work-in-progress draft about parsing and canonicalizing URLs.
>
> Adam
>
>
> On Tue, Sep 21, 2010 at 3:40 PM, Ojan Vafai  wrote:
>> appendParameter/clearParameter seems fine to me.
>> On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. 
>> wrote:
>>>
>>> On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth  wrote:
>>> > Ok.  I'm sold on having an API for constructing query parameters.
>>> > Thoughts on what it should look like?  Here's what jQuery does:
>>> >
>>> > http://api.jquery.com/jQuery.get/
>>> >
>>> > Essentially, you supply a JSON object containing the parameters.  They
>>> > also have some magical syntax for specifying multiple instances of the
>>> > same parameter name.  I like the easy of supplying a JSON object, but
>>> > I'm not in love with the magical syntax.  An alternative is to use two
>>> > APIs, like we current have for reading the parameter values.
>>>
>>> jQuery's syntax isn't magical - the example they give using the query
>>> param name of 'choices[]' is doing that because PHP requires a [] at
>>> the end of the query param name to signal it that you want multiple
>>> values.  It's opaque, though - you could just as easily have left off
>>> the '[]' and it would have worked the same.
>>>
>>> The switch is just whether you pass an array or a string (maybe they
>>> support numbers too?).
>>>
>>> I recommend the method be called append*, so you can use it both for
>>> first sets and later additions (this is particularly useful if you're
>>> just looping through some data).  This obviously would then need a
>>> clear functionality as well.
>>>
>>> ~TJ
>>>
>>
>>
>

Re: A URL API

[Adam Barth]

On Sun, Sep 19, 2010 at 10:50 PM, Darin Fisher  wrote:
> On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky  wrote:
>>  * A getCommonBaseSpec() method that will take two URIs and return a
>>    URI string they could both be relative to, if any.
>>  * A getRelativeSpec() method that takes two URIs and returns a
>>    string that represents one as a relative URI relative to the
>>    other (if this is possible).
>
> ^^^ these are convenient

I haven't added these yet, but I certainly wouldn't rule out adding
them in the future.

Adam

Re: A URL API

[Ojan Vafai]

appendParameter/clearParameter seems fine to me.

On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. wrote:

> On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth  wrote:
> > Ok.  I'm sold on having an API for constructing query parameters.
> > Thoughts on what it should look like?  Here's what jQuery does:
> >
> > http://api.jquery.com/jQuery.get/
> >
> > Essentially, you supply a JSON object containing the parameters.  They
> > also have some magical syntax for specifying multiple instances of the
> > same parameter name.  I like the easy of supplying a JSON object, but
> > I'm not in love with the magical syntax.  An alternative is to use two
> > APIs, like we current have for reading the parameter values.
>
> jQuery's syntax isn't magical - the example they give using the query
> param name of 'choices[]' is doing that because PHP requires a [] at
> the end of the query param name to signal it that you want multiple
> values.  It's opaque, though - you could just as easily have left off
> the '[]' and it would have worked the same.
>
> The switch is just whether you pass an array or a string (maybe they
> support numbers too?).
>
> I recommend the method be called append*, so you can use it both for
> first sets and later additions (this is particularly useful if you're
> just looping through some data).  This obviously would then need a
> clear functionality as well.
>
> ~TJ
>
>

Re: A URL API

[Tab Atkins Jr.]

On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth  wrote:
> Ok.  I'm sold on having an API for constructing query parameters.
> Thoughts on what it should look like?  Here's what jQuery does:
>
> http://api.jquery.com/jQuery.get/
>
> Essentially, you supply a JSON object containing the parameters.  They
> also have some magical syntax for specifying multiple instances of the
> same parameter name.  I like the easy of supplying a JSON object, but
> I'm not in love with the magical syntax.  An alternative is to use two
> APIs, like we current have for reading the parameter values.

jQuery's syntax isn't magical - the example they give using the query
param name of 'choices[]' is doing that because PHP requires a [] at
the end of the query param name to signal it that you want multiple
values.  It's opaque, though - you could just as easily have left off
the '[]' and it would have worked the same.

The switch is just whether you pass an array or a string (maybe they
support numbers too?).

I recommend the method be called append*, so you can use it both for
first sets and later additions (this is particularly useful if you're
just looping through some data).  This obviously would then need a
clear functionality as well.

~TJ

Re: A URL API

[Devdatta Akhawe]

>
> Perhaps appendParameter("x", "a", "b", "c") ?
>

where appendParameter is the second API  - separate from setParameter?

so appendParmeter("x',"a","b","c"); setParameter("x","a")
would result in ?x=a

and without the second function call it would be
?x=a&x=b&x=c

I am fine with this.

cheers
devdatta

> Adam
>

Re: A URL API

[Doug Schepers]

Hi, Adam-

I really like this idea.  Of course there are scripts out there that do 
most (all?) of this, but exposing it as an interface seems useful to me.


I proposed something similar in my SVG Params spec [1][2][3], though 
yours is better thought out.  One difference is that I was specifically 
looking at parameters, not merely as a function of the URL, but through 
any mechanism that the language provides; for example, HTML can pass 
parameters into a file referenced through the  element with 
child  elements.  Do you think there's some way to reconcile that 
with your proposal?


[1] http://www.w3.org/TR/SVGParam/
[2] http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[3] http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Adam Barth wrote (on 9/17/10 2:05 PM):

On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:

 On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher  wrote:

 On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke
 wrote:

 That sounds good to me. In general I think it would be great if there were
 standard APIs for URI/IRI construction, parsing and resolution...


 Yes, that sounds pretty good to me too.


 This has annoyed me for a while too.  I'll write up a spec.


Here's a sketch:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en

Adam

Re: A URL API

[Mihai Parparita]

On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith  wrote:
> IOW, what are the cases where an XHR instance wants to use a lot o query 
> params?

I'm sure there are other examples, and it depends by what you mean by
"a lot," but here are all the parameters that Google Reader sends when
requesting feed data (Reader uses the goog.Uri classes from the
Closure library that Ojan mentioned earlier):

trans:true
ot:1282413600
r:n
xt:user/14548369432350969777/state/com.google/read
sharers:CKfbjpeeFxgB
n:20
refresh:true
ck:1285006428691
client:scroll

Mihai

Re: A URL API

[Garrett Smith]

On 9/21/10, Ojan Vafai  wrote:
> How about setParameter(name, value...) that takes var_args number of values?
> Alternately, it could take either a DOMString or an Array for the
> value. I prefer the var_args.
>
Why?

A user-defined fallback will be necessary for a while.

The downside of using varargs is that any user-defined fallback has to
resort to using the arguments object. Your alternate doesn't have that
problem.
-- 
Garrett

Re: A URL API

[Adam Barth]

On Tue, Sep 21, 2010 at 12:51 AM, Devdatta Akhawe  wrote:
> On 21 September 2010 00:47, Ojan Vafai  wrote:
>> How about setParameter(name, value...) that takes var_args number of values?
>> Alternately, it could take either a DOMString or an Array for the
>> value. I prefer the var_args.
>
> What happens when I do
> setParameter('x','a','b','c');
>
> and now want to add another - I will have to do weird things like
> getting the parameter via getAllParameter and then append to the array
> and function.call or something like that
>
> doesn't look very nice according to me - I like the separation into 2
> APIs because I think that makes the common case of single parameter
> values clean and robust

Perhaps appendParameter("x", "a", "b", "c") ?

Adam

Re: A URL API

[Devdatta Akhawe]

On 21 September 2010 00:47, Ojan Vafai  wrote:
> How about setParameter(name, value...) that takes var_args number of values?
> Alternately, it could take either a DOMString or an Array for the
> value. I prefer the var_args.

What happens when I do
setParameter('x','a','b','c');

and now want to add another - I will have to do weird things like
getting the parameter via getAllParameter and then append to the array
and function.call or something like that

doesn't look very nice according to me - I like the separation into 2
APIs because I think that makes the common case of single parameter
values clean and robust


cheers
devdatta


> Also, getParameterByName and getAllParametersByName seem unnecessarily
> wordy. How about getParameter/getParameterAll to match
> querySelector/querySelectorAll? Putting "All" at the end is admittedly
> awkward, but this is the uncommon case, so I'm OK with it for making the
> common case less wordy.
> Ojan
> On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth  wrote:
>>
>> Ok.  I'm sold on having an API for constructing query parameters.
>> Thoughts on what it should look like?  Here's what jQuery does:
>>
>> http://api.jquery.com/jQuery.get/
>>
>> Essentially, you supply a JSON object containing the parameters.  They
>> also have some magical syntax for specifying multiple instances of the
>> same parameter name.  I like the easy of supplying a JSON object, but
>> I'm not in love with the magical syntax.  An alternative is to use two
>> APIs, like we current have for reading the parameter values.
>>
>> Adam
>>
>>
>> On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe 
>> wrote:
>> > or any webservice that likes to have lots of query parameters - Google
>> > Search for example.
>> >
>> > In general, why would you not want a robust way to make complicated
>> > queries - those who are making simple queries and prefer simple one
>> > liners can continue using it.
>> >
>> >
>> > On 20 September 2010 23:42, Darin Fisher  wrote:
>> >> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith
>> >> 
>> >> wrote:
>> >>>
>> >>> On 9/20/10, Julian Reschke  wrote:
>> >>> > On 20.09.2010 18:56, Garrett Smith wrote:
>> >>> [...]
>> >>> >> Requests that don't have lot of parameters are often simple
>> >>> >> one-liners:
>> >>> >>
>> >>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>> >>> >
>> >>> > That's exactly the kind of code that will fail once "pid" and "zip"
>> >>> > contain things you don't expecz.
>> >>> >
>> >>> >> What XHRs have complicated URL with a lot of query parameters?
>> >>> >
>> >>> > What XHRs?
>> >>> >
>> >>> IOW, what are the cases where an XHR instance wants to use a lot o
>> >>> query
>> >>> params?
>> >>>
>> >>
>> >> Probably when speaking to a HTTP server designed to take input from an
>> >> HTML
>> >> form.
>> >> -Darin
>> >>
>> >
>>
>
>

Re: A URL API

[Ojan Vafai]

How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an Array for the
value. I prefer the var_args.

Also, getParameterByName and getAllParametersByName seem unnecessarily
wordy. How about getParameter/getParameterAll to match
querySelector/querySelectorAll? Putting "All" at the end is admittedly
awkward, but this is the uncommon case, so I'm OK with it for making the
common case less wordy.

Ojan

On Tue, Sep 21, 2010 at 4:56 PM, Adam Barth  wrote:

> Ok.  I'm sold on having an API for constructing query parameters.
> Thoughts on what it should look like?  Here's what jQuery does:
>
> http://api.jquery.com/jQuery.get/
>
> Essentially, you supply a JSON object containing the parameters.  They
> also have some magical syntax for specifying multiple instances of the
> same parameter name.  I like the easy of supplying a JSON object, but
> I'm not in love with the magical syntax.  An alternative is to use two
> APIs, like we current have for reading the parameter values.
>
> Adam
>
>
> On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe 
> wrote:
> > or any webservice that likes to have lots of query parameters - Google
> > Search for example.
> >
> > In general, why would you not want a robust way to make complicated
> > queries - those who are making simple queries and prefer simple one
> > liners can continue using it.
> >
> >
> > On 20 September 2010 23:42, Darin Fisher  wrote:
> >> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith  >
> >> wrote:
> >>>
> >>> On 9/20/10, Julian Reschke  wrote:
> >>> > On 20.09.2010 18:56, Garrett Smith wrote:
> >>> [...]
> >>> >> Requests that don't have lot of parameters are often simple
> one-liners:
> >>> >>
> >>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
> >>> >
> >>> > That's exactly the kind of code that will fail once "pid" and "zip"
> >>> > contain things you don't expecz.
> >>> >
> >>> >> What XHRs have complicated URL with a lot of query parameters?
> >>> >
> >>> > What XHRs?
> >>> >
> >>> IOW, what are the cases where an XHR instance wants to use a lot o
> query
> >>> params?
> >>>
> >>
> >> Probably when speaking to a HTTP server designed to take input from an
> HTML
> >> form.
> >> -Darin
> >>
> >
>
>

Re: A URL API

[Devdatta Akhawe]

+1 for 2 APIs - this whole multiple parameters with the same value is
too annoying imho and unnecessary for new web services . It should be
there only for old services that are also accessed via basic HTML
forms

cheers
devdatta

On 20 September 2010 23:56, Adam Barth  wrote:
> Ok.  I'm sold on having an API for constructing query parameters.
> Thoughts on what it should look like?  Here's what jQuery does:
>
> http://api.jquery.com/jQuery.get/
>
> Essentially, you supply a JSON object containing the parameters.  They
> also have some magical syntax for specifying multiple instances of the
> same parameter name.  I like the easy of supplying a JSON object, but
> I'm not in love with the magical syntax.  An alternative is to use two
> APIs, like we current have for reading the parameter values.
>
> Adam
>
>
> On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe  
> wrote:
>> or any webservice that likes to have lots of query parameters - Google
>> Search for example.
>>
>> In general, why would you not want a robust way to make complicated
>> queries - those who are making simple queries and prefer simple one
>> liners can continue using it.
>>
>>
>> On 20 September 2010 23:42, Darin Fisher  wrote:
>>> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith 
>>> wrote:

 On 9/20/10, Julian Reschke  wrote:
 > On 20.09.2010 18:56, Garrett Smith wrote:
 [...]
 >> Requests that don't have lot of parameters are often simple one-liners:
 >>
 >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
 >
 > That's exactly the kind of code that will fail once "pid" and "zip"
 > contain things you don't expecz.
 >
 >> What XHRs have complicated URL with a lot of query parameters?
 >
 > What XHRs?
 >
 IOW, what are the cases where an XHR instance wants to use a lot o query
 params?

>>>
>>> Probably when speaking to a HTTP server designed to take input from an HTML
>>> form.
>>> -Darin
>>>
>>
>

Re: A URL API

[Adam Barth]

Ok.  I'm sold on having an API for constructing query parameters.
Thoughts on what it should look like?  Here's what jQuery does:

http://api.jquery.com/jQuery.get/

Essentially, you supply a JSON object containing the parameters.  They
also have some magical syntax for specifying multiple instances of the
same parameter name.  I like the easy of supplying a JSON object, but
I'm not in love with the magical syntax.  An alternative is to use two
APIs, like we current have for reading the parameter values.

Adam


On Mon, Sep 20, 2010 at 11:47 PM, Devdatta Akhawe  wrote:
> or any webservice that likes to have lots of query parameters - Google
> Search for example.
>
> In general, why would you not want a robust way to make complicated
> queries - those who are making simple queries and prefer simple one
> liners can continue using it.
>
>
> On 20 September 2010 23:42, Darin Fisher  wrote:
>> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith 
>> wrote:
>>>
>>> On 9/20/10, Julian Reschke  wrote:
>>> > On 20.09.2010 18:56, Garrett Smith wrote:
>>> [...]
>>> >> Requests that don't have lot of parameters are often simple one-liners:
>>> >>
>>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>>> >
>>> > That's exactly the kind of code that will fail once "pid" and "zip"
>>> > contain things you don't expecz.
>>> >
>>> >> What XHRs have complicated URL with a lot of query parameters?
>>> >
>>> > What XHRs?
>>> >
>>> IOW, what are the cases where an XHR instance wants to use a lot o query
>>> params?
>>>
>>
>> Probably when speaking to a HTTP server designed to take input from an HTML
>> form.
>> -Darin
>>
>

Re: A URL API

[Devdatta Akhawe]

or any webservice that likes to have lots of query parameters - Google
Search for example.

In general, why would you not want a robust way to make complicated
queries - those who are making simple queries and prefer simple one
liners can continue using it.


On 20 September 2010 23:42, Darin Fisher  wrote:
> On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith 
> wrote:
>>
>> On 9/20/10, Julian Reschke  wrote:
>> > On 20.09.2010 18:56, Garrett Smith wrote:
>> [...]
>> >> Requests that don't have lot of parameters are often simple one-liners:
>> >>
>> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>> >
>> > That's exactly the kind of code that will fail once "pid" and "zip"
>> > contain things you don't expecz.
>> >
>> >> What XHRs have complicated URL with a lot of query parameters?
>> >
>> > What XHRs?
>> >
>> IOW, what are the cases where an XHR instance wants to use a lot o query
>> params?
>>
>
> Probably when speaking to a HTTP server designed to take input from an HTML
> form.
> -Darin
>

Re: A URL API

[Darin Fisher]

On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith wrote:

> On 9/20/10, Julian Reschke  wrote:
> > On 20.09.2010 18:56, Garrett Smith wrote:
> [...]
> >> Requests that don't have lot of parameters are often simple one-liners:
> >>
> >> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
> >
> > That's exactly the kind of code that will fail once "pid" and "zip"
> > contain things you don't expecz.
> >
> >> What XHRs have complicated URL with a lot of query parameters?
> >
> > What XHRs?
> >
> IOW, what are the cases where an XHR instance wants to use a lot o query
> params?
>
>
Probably when speaking to a HTTP server designed to take input from an HTML
form.

-Darin

Re: A URL API

[Garrett Smith]

On 9/20/10, Julian Reschke  wrote:
> On 20.09.2010 18:56, Garrett Smith wrote:
[...]
>> Requests that don't have lot of parameters are often simple one-liners:
>>
>> url = "/getShipping/?zip=" + zip + "&pid=" + pid;
>
> That's exactly the kind of code that will fail once "pid" and "zip"
> contain things you don't expecz.
>
>> What XHRs have complicated URL with a lot of query parameters?
>
> What XHRs?
>
IOW, what are the cases where an XHR instance wants to use a lot o query params?

Garrett

Re: A URL API

[Julian Reschke]

On 20.09.2010 18:56, Garrett Smith wrote:

No idea; I wouldn't expect it to work, even if some browser actually
supported something other than GET|POST. I've always used "get" or
"post" and that's what's stated in HTML4.



Might a large-ish form request, a standard form submission be a better
alternative to XHR?


Depends on the application.

One reason to use XHR is that you want to interact with an HTTP service 
that hasn't been written for a web browser.


Whether services like this require complicated URI construction is a 
separate issue. Some do. And I'm pretty sure that people *will* get URI 
construction wrong due to delimiters, non-ASCII characters and so on.



Requests that don't have lot of parameters are often simple one-liners:

url = "/getShipping/?zip=" + zip + "&pid=" + pid;


That's exactly the kind of code that will fail once "pid" and "zip" 
contain things you don't expecz.



What XHRs have complicated URL with a lot of query parameters?


What XHRs?

Best regards, Julian

Re: A URL API

[Garrett Smith]

On 9/20/10, Julian Reschke  wrote:
> On 20.09.2010 09:22, Garrett Smith wrote:
>> ...
>> I see setParameterValues there. Useful to build URLs for XHR. But OTOH
>> -- Ajax that is using a lot of parameters, might be better using a
>> form. Usually Ajax requests are simple requests -- not a large form
>> submission. Sorry just have to be devils advocate on the necessity of
>> the thing.
>> ...
>
> How do you use a form to build a request other than GET/POST?
>
>
No idea; I wouldn't expect it to work, even if some browser actually
supported something other than GET|POST. I've always used "get" or
"post" and that's what's stated in HTML4.



Might a large-ish form request, a standard form submission be a better
alternative to XHR?

Requests that don't have lot of parameters are often simple one-liners:

url = "/getShipping/?zip=" + zip + "&pid=" + pid;

What XHRs have complicated URL with a lot of query parameters?

Garrett

Re: A URL API

[Anne van Kesteren]

On Mon, 20 Sep 2010 10:01:01 +0200, Adam Barth  wrote:

Using the method attribute of the form element.


It will not get you further than GET/POST; and PUT/DELETE with same-origin  
limitation. It also does not allow for custom headers, custom entity body,  
etc.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: A URL API

[Julian Reschke]

On 20.09.2010 10:01, Adam Barth wrote:

On Mon, Sep 20, 2010 at 12:34 AM, Julian Reschke  wrote:

On 20.09.2010 09:22, Garrett Smith wrote:


...
I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.
...


How do you use a form to build a request other than GET/POST?


Using the method attribute of the form element.


OK. So I set the method attribute to "FOOBAR", and then how do I proceed 
generating an HTTP request from there?


Best regards, Julian

Re: A URL API

[Adam Barth]

On Mon, Sep 20, 2010 at 12:34 AM, Julian Reschke  wrote:
> On 20.09.2010 09:22, Garrett Smith wrote:
>>
>> ...
>> I see setParameterValues there. Useful to build URLs for XHR. But OTOH
>> -- Ajax that is using a lot of parameters, might be better using a
>> form. Usually Ajax requests are simple requests -- not a large form
>> submission. Sorry just have to be devils advocate on the necessity of
>> the thing.
>> ...
>
> How do you use a form to build a request other than GET/POST?

Using the method attribute of the form element.

Adam

Re: A URL API

[Julian Reschke]

On 20.09.2010 09:22, Garrett Smith wrote:

...
I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.
...


How do you use a form to build a request other than GET/POST?

Re: A URL API

[Garrett Smith]

On 9/19/10, Julian Reschke  wrote:
> On 20.09.2010 08:27, Adam Barth wrote:
>> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe
>> wrote:

> Keep in mind that the original use case was making life easier for
> people using XmlHttpRequest, and that covers many more use cases than forms.
>
Yep, I just took a quick glance at the Closure docs Ojan linked up
too. Docs look good; haven't looked at the code.

I see setParameterValues there. Useful to build URLs for XHR. But OTOH
-- Ajax that is using a lot of parameters, might be better using a
form. Usually Ajax requests are simple requests -- not a large form
submission. Sorry just have to be devils advocate on the necessity of
the thing.

BTW it's XMLHttpRequest -- I can't help but memorize these things
after typing them a few hundred times.

Regards.

Re: A URL API

[Julian Reschke]

On 20.09.2010 08:27, Adam Barth wrote:

On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe  wrote:

1) There are now two methods for getting at the URL parameters.  The


and none for setting them?


That's correct.  Looking at various libraries, there seems to be much
more interested in paring out query parameters than for constructing
them.  One popular JavaScript library did have an API that took a
dictionary and built a query string out of it.  I imagine most folks
just use the HTML Form element.
...


If a new standard API is added, it also should cover construction. 
Construction is hard, due to the different escaping rules for paths, 
query parameters etc.


Keep in mind that the original use case was making life easier for 
people using XmlHttpRequest, and that covers many more use cases than forms.


Best regards, Julian

Re: A URL API

[Ojan Vafai]

On Mon, Sep 20, 2010 at 4:27 PM, Adam Barth  wrote:

> On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe 
> wrote:
> >> 1) There are now two methods for getting at the URL parameters.  The
> >
> > and none for setting them?
>
> That's correct.  Looking at various libraries, there seems to be much
> more interested in paring out query parameters than for constructing
> them.  One popular JavaScript library did have an API that took a
> dictionary and built a query string out of it.  I imagine most folks
> just use the HTML Form element.


That's not true of Google's Closure library:
http://closure-library.googlecode.com/svn/docs/class_goog_Uri.html (see the
set* methods).

Re: A URL API

[Julian Reschke]

On 20.09.2010 07:51, Adam Barth wrote:

...

2)  Why lastPathComponent as opposed to, say, fileName?


Renamed to fileName.
...


-1

Please stay consistent with the terminology in the URI spec.


Best regards, Julian

Re: A URL API

[Adam Barth]

On Sun, Sep 19, 2010 at 10:48 PM, Devdatta Akhawe  wrote:
>> 1) There are now two methods for getting at the URL parameters.  The
>
> and none for setting them?

That's correct.  Looking at various libraries, there seems to be much
more interested in paring out query parameters than for constructing
them.  One popular JavaScript library did have an API that took a
dictionary and built a query string out of it.  I imagine most folks
just use the HTML Form element.

Adam

Re: A URL API

[Boris Zbarsky]

On 9/20/10 2:02 AM, Adam Barth wrote:

That document is pretty rough, but I welcome any feedback you have.


I don't have anything concrete at the moment, past a link to 
http://hg.mozilla.org/mozilla-central/file/8b47f3cabf9f/netwerk/base/public/nsIStandardURL.idl#l53 
for some of the differences in the way Gecko parses various hierarchical 
URIs based on its built-in knowledge of the scheme


-Boris

Re: A URL API

[Adam Barth]

On Sun, Sep 19, 2010 at 10:56 PM, Boris Zbarsky  wrote:
> On 9/20/10 1:51 AM, Adam Barth wrote:
>>>
>>> 1)  The reference chain for actually parsing a URI terminates in HTML5
>>> referencing the IRI RFC, which doesn't seem to define a parsing
>>> algorithm.
>>>  Did I just miss it?
>>
>> I'm working on fixing that problem too:
>>
>> http://github.com/abarth/url-spec/blob/master/drafts/url.txt
>
> Ah, excellent.  And even better, it already has open issues on the things I
> wanted to double-check.  ;)

That document is pretty rough, but I welcome any feedback you have.

Adam

Re: A URL API

[Boris Zbarsky]

On 9/20/10 1:51 AM, Adam Barth wrote:

1)  The reference chain for actually parsing a URI terminates in HTML5
referencing the IRI RFC, which doesn't seem to define a parsing algorithm.
  Did I just miss it?


I'm working on fixing that problem too:

http://github.com/abarth/url-spec/blob/master/drafts/url.txt


Ah, excellent.  And even better, it already has open issues on the 
things I wanted to double-check.  ;)


-Boris

Re: A URL API

[Adam Barth]

On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky  wrote:
> On 9/20/10 1:02 AM, Adam Barth wrote:
>> I've updated the document:
>>
>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#
>
> General comments based on a quick read (and ignoring various typos that I
> figure we'll fix in due course):
>
> 1)  The reference chain for actually parsing a URI terminates in HTML5
> referencing the IRI RFC, which doesn't seem to define a parsing algorithm.
>  Did I just miss it?

I'm working on fixing that problem too:

http://github.com/abarth/url-spec/blob/master/drafts/url.txt

> 2)  Why lastPathComponent as opposed to, say, fileName?

Renamed to fileName.

> 3)  Why is lastPathComponent readonly?

Made mutable.

> 4)  Things Gecko has on its URI objects that this seems to be missing
>    and that might be useful and aren't obviously available via
>    existing facilities of this interface:

I'll look at these in detail later.

Adam

Re: A URL API

[Darin Fisher]

On Sun, Sep 19, 2010 at 10:41 PM, Boris Zbarsky  wrote:

> On 9/20/10 1:02 AM, Adam Barth wrote:
>
>> I've updated the document:
>>
>>
>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#
>>
>
> General comments based on a quick read (and ignoring various typos that I
> figure we'll fix in due course):
>
> 1)  The reference chain for actually parsing a URI terminates in HTML5
> referencing the IRI RFC, which doesn't seem to define a parsing algorithm.
>  Did I just miss it?
>
> 2)  Why lastPathComponent as opposed to, say, fileName?
>
> 3)  Why is lastPathComponent readonly?
>
> 4)  Things Gecko has on its URI objects that this seems to be missing
>and that might be useful and aren't obviously available via
>existing facilities of this interface:
>
>  * An equals() method that takes another URI object
>  * An 'asciiSpec' property (Host IDN-escaped as needed, other parts
>URL-escaped).
>  * An 'asciiHost' property
>

asciiSpec/Host is the canonical form, which is what Location currently
outputs.  gecko's URI class has the UTF-8 spec/host attributes to be more
friendly to UI code that might prefer the non-IDN version of the strings.



>  * A 'param' property (for things following ';')
>

This one seems unused as best as I can tell.


>  * A 'directory' property (which may be similar to getting the
>pathname and then dropping everything after the last '/'... not
>sure).
>  * fileBaseName and fileExtension (URI might not be the right place
>for these, though).
>

^^^ extracting those is pretty simple given the currently proposed
interface.



>  * A getCommonBaseSpec() method that will take two URIs and return a
>URI string they could both be relative to, if any.
>  * A getRelativeSpec() method that takes two URIs and returns a
>string that represents one as a relative URI relative to the
>other (if this is possible).
>

^^^ these are convenient

-Darin


>
> -Boris
>
>
>

Re: A URL API

[Devdatta Akhawe]

>
> 1) There are now two methods for getting at the URL parameters.  The

and none for setting them?


cheers
devdatta


> 2) The origin attribute is now readonly.  Once I wired up the origin
> attribute to the actual definition of how to compute the origin of a
> URL, it became obvious that we don't want to support assigning to the
> attribute.  In particular, it doesn't seems particularly meaningful to
> assign the string "null" to the attribute even though that's a
> perfectly reasonable value for the attribute to return.
>
> 3) I've added definitions for what the interface actually does.
>
> In response to folks who think we should add these APIs to
> HTMLAnchorElement and Location, I agree.  Currently, the draft is
> written to refer to HTML5 for the definitions of the common elements,
> but we could easily reverse that dependency or incorporate this API
> into HTML5.
>
> Adam
>
>

Re: A URL API

[Boris Zbarsky]

On 9/20/10 1:02 AM, Adam Barth wrote:

I've updated the document:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#


General comments based on a quick read (and ignoring various typos that 
I figure we'll fix in due course):


1)  The reference chain for actually parsing a URI terminates in HTML5 
referencing the IRI RFC, which doesn't seem to define a parsing 
algorithm.  Did I just miss it?


2)  Why lastPathComponent as opposed to, say, fileName?

3)  Why is lastPathComponent readonly?

4)  Things Gecko has on its URI objects that this seems to be missing
and that might be useful and aren't obviously available via
existing facilities of this interface:

  * An equals() method that takes another URI object
  * An 'asciiSpec' property (Host IDN-escaped as needed, other parts
URL-escaped).
  * An 'asciiHost' property
  * A 'param' property (for things following ';')
  * A 'directory' property (which may be similar to getting the
pathname and then dropping everything after the last '/'... not
sure).
  * fileBaseName and fileExtension (URI might not be the right place
for these, though).
  * A getCommonBaseSpec() method that will take two URIs and return a
URI string they could both be relative to, if any.
  * A getRelativeSpec() method that takes two URIs and returns a
string that represents one as a relative URI relative to the
other (if this is possible).

-Boris

Re: A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 5:48 PM, Tab Atkins Jr.  wrote:
> On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth  wrote:
>> I've removed the searchParameters attribute from the URL interface for
>> the time being.  We can consider adding it back at a later time.
>
> ;_;
>
> Just today my cubemate asked me if there was any way to get at the
> search parameters of a URL without parsing it himself.  I replied "No,
> but abarth started working on an API for it today.".
>
> That said, Garrett's right.  The values of the dict should be arrays.
> Most of the time they'll be single-element arrays, but the benefit of
> having a consistent type of value at all times is better than the
> benefit of being able to omit "[0]" from parts of your code.

I've updated the document:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#

Changes:

1) There are now two methods for getting at the URL parameters.  The
easy one, which just returns the last value if there are more than one
parameter with the same name (I checked a bunch of libraries and using
the last of duplicates seemed to be more popular), and the advanced
one, which returns an array containing all of the values.

2) The origin attribute is now readonly.  Once I wired up the origin
attribute to the actual definition of how to compute the origin of a
URL, it became obvious that we don't want to support assigning to the
attribute.  In particular, it doesn't seems particularly meaningful to
assign the string "null" to the attribute even though that's a
perfectly reasonable value for the attribute to return.

3) I've added definitions for what the interface actually does.

In response to folks who think we should add these APIs to
HTMLAnchorElement and Location, I agree.  Currently, the draft is
written to refer to HTML5 for the definitions of the common elements,
but we could easily reverse that dependency or incorporate this API
into HTML5.

Adam

Re: A URL API

[Tab Atkins Jr.]

On Sun, Sep 19, 2010 at 5:03 PM, Devdatta Akhawe  wrote:
> hi
>
> Is the word 'hash' for fragment identifiers common? I personally
> prefer the attribute being called 'fragment' or 'fragmentID' over
> 'hash' - its the standard afaik in all the RFCs.

'hash' is the name given to the fragment identifier in the Location
object.  It's pretty common.

~TJ

Re: A URL API

[Devdatta Akhawe]

hi

Is the word 'hash' for fragment identifiers common? I personally
prefer the attribute being called 'fragment' or 'fragmentID' over
'hash' - its the standard afaik in all the RFCs.

regards
devdatta

On 19 September 2010 15:47, João Eiras  wrote:
>
>> That would be different behavior than what Location and HTMLAnchorElement
>> do; they unescape various componenents. Is the benefit worth the divergence?
>>
>> As a side note, an out-of-document HTMLAnchorElement already provides most
>> of the functionality of this interface. Things it can't do:
>> - Resolve a relative URL against no base at all (probably not very useful
>> since the interface can only represent an absolute URL).
>> - Resolve against an arbitrary base (maybe you could do it awkwardly using
>>  tag tricks).
>> - Read or write the lastPathComponent or origin without further parsing
>> (should origin really be writable? That's kind of weird...)
>> - Read search parameters conveniently without parsing.
>>
>> It might be nice to provide the parts of this that make sense on
>> HTMLAnchorElement and Location, then see if a new interface really pulls its
>> weight.
>>
>
> I idea too. I would rather extend "Location" to include these features, so
> they would be immediately available in links and the location object. And
> make Location into a constructor "new Location(url, base)"
>
>

Re: A URL API

[João Eiras]

That would be different behavior than what Location and HTMLAnchorElement do; 
they unescape various componenents. Is the benefit worth the divergence?

As a side note, an out-of-document HTMLAnchorElement already provides most of 
the functionality of this interface. Things it can't do:
- Resolve a relative URL against no base at all (probably not very useful since 
the interface can only represent an absolute URL).
- Resolve against an arbitrary base (maybe you could do it awkwardly using 
 tag tricks).
- Read or write the lastPathComponent or origin without further parsing (should 
origin really be writable? That's kind of weird...)
- Read search parameters conveniently without parsing.

It might be nice to provide the parts of this that make sense on 
HTMLAnchorElement and Location, then see if a new interface really pulls its 
weight.



I idea too. I would rather extend "Location" to include these features, so they would be 
immediately available in links and the location object. And make Location into a constructor 
"new Location(url, base)"

Re: A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 9:52 PM, Maciej Stachowiak  wrote:
> On Sep 17, 2010, at 1:01 PM, Adam Barth wrote:
>> Another piece of functionality that's missing from HTMLAnchorElement
>> is the automatic stringification of URL objects.  That lets you pass
>> URL objects into APIs that expect URLs represented as strings.  It's
>> unlikely that we'd want to add that part of the interface to
>> HTMLAnchorElement.
>
> That does not match my recollection or testing:
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Ca%20href%3D%22http%3A%2F%2Fsome-domain.com%2Fsome%2Fpath%23frag%22%20id%3Dtest%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.write(document.getElementById(%22test%22))%3B%0A%3C%2Fscript%3E

Woah, that's pretty cool.

Adam

Re: A URL API

[Garrett Smith]

On 9/17/10, Devdatta Akhawe  wrote:
> hi
>
>> You mean you didn't mention that I drafted a much better one over two
>> years ago?
>>
>
> Garrett : could you send a link to your ES4 draft/proposal ? My simple
> google skills couldn't find it.
>
I thought I linked to that earlier but don't see it now. Sorry and
thanks for pointing it out.

http://dhtmlkitchen.com/rec/URI.html

Untouched for 3 years now, has some broken links, including a
nostalgic link to "Sun Microsystems".

That API put the parameter map right into the URI object itself. I now
see that as a design mistake. The LiveDictionary would make the
object's interface simpler by moving the removeParameter,
deleteParameter, etc to the generic Dictionary interface.

[...]

Regards,

Garrett

Re: A URL API

[Maciej Stachowiak]

On Sep 17, 2010, at 1:01 PM, Adam Barth wrote:

> On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak  wrote:
> 
>> It might be nice to provide the parts of this that make sense on 
>> HTMLAnchorElement and Location, then see if a new interface really pulls its 
>> weight.
> 
> Another piece of functionality that's missing from HTMLAnchorElement
> is the automatic stringification of URL objects.  That lets you pass
> URL objects into APIs that expect URLs represented as strings.  It's
> unlikely that we'd want to add that part of the interface to
> HTMLAnchorElement.

That does not match my recollection or testing:

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Ca%20href%3D%22http%3A%2F%2Fsome-domain.com%2Fsome%2Fpath%23frag%22%20id%3Dtest%3E%3C%2Fa%3E%0A%3Cscript%3E%0Adocument.write(document.getElementById(%22test%22))%3B%0A%3C%2Fscript%3E

Good point about the Worker use case where there is no DOM.

Regards,
Maciej

Re: A URL API

[Devdatta Akhawe]

hi

> You mean you didn't mention that I drafted a much better one over two
> years ago?
>

Garrett : could you send a link to your ES4 draft/proposal ? My simple
google skills couldn't find it.

thanks
devdatta


> And you felt this API was worth mentioning?
>
> My criticism is spot-on and appropriate. Cursory, dismissive and
> thoughtless replies are as inappropriate and counterproductive as
> flippant messages I'm seeing in my inbox. And I'm not about to be
> pigeonholed or scapegoated into being the bad guy here. Make sense?
>
>> That said, Garrett's right.
>
> My arguments are supported by the reasons that I provided; nothing
> more, nothing less.
>
> Garrett
>
>

Re: A URL API

[Garrett Smith]

On 9/17/10, Tab Atkins Jr.  wrote:
> On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth  wrote:
>> I've removed the searchParameters attribute from the URL interface for
>> the time being.  We can consider adding it back at a later time.
>
> ;_;
>
> Just today my cubemate asked me if there was any way to get at the
> search parameters of a URL without parsing it himself.  I replied "No,
> but abarth started working on an API for it today.".
>
You mean you didn't mention that I drafted a much better one over two
years ago?

And you felt this API was worth mentioning?

My criticism is spot-on and appropriate. Cursory, dismissive and
thoughtless replies are as inappropriate and counterproductive as
flippant messages I'm seeing in my inbox. And I'm not about to be
pigeonholed or scapegoated into being the bad guy here. Make sense?

> That said, Garrett's right.

My arguments are supported by the reasons that I provided; nothing
more, nothing less.

Garrett

Re: A URL API

[Nathan]

Tab Atkins Jr. wrote:

On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth  wrote:

I've removed the searchParameters attribute from the URL interface for
the time being.  We can consider adding it back at a later time.


;_;

Just today my cubemate asked me if there was any way to get at the
search parameters of a URL without parsing it himself.  I replied "No,
but abarth started working on an API for it today.".

That said, Garrett's right.  The values of the dict should be arrays.
Most of the time they'll be single-element arrays, but the benefit of
having a consistent type of value at all times is better than the
benefit of being able to omit "[0]" from parts of your code.


+1 in every way, and if somebody wanted to miss the [0] they could make 
a simple get function which returned array or single element based on 
array.length, in userland.


regards,

nathan

Re: A URL API

[Tab Atkins Jr.]

On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth  wrote:
> I've removed the searchParameters attribute from the URL interface for
> the time being.  We can consider adding it back at a later time.

;_;

Just today my cubemate asked me if there was any way to get at the
search parameters of a URL without parsing it himself.  I replied "No,
but abarth started working on an API for it today.".

That said, Garrett's right.  The values of the dict should be arrays.
Most of the time they'll be single-element arrays, but the benefit of
having a consistent type of value at all times is better than the
benefit of being able to omit "[0]" from parts of your code.

~TJ

Re: A URL API

[Adam Barth]

I've removed the searchParameters attribute from the URL interface for
the time being.  We can consider adding it back at a later time.

Adam


On Fri, Sep 17, 2010 at 5:21 PM, Garrett Smith  wrote:
> On 9/17/10, Adam Barth  wrote:
>> On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith 
>> wrote:
>>> On 9/17/10, Adam Barth  wrote:
 On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith 
 wrote:
> Where is Dictionary defined?

 It might not be defined yet.
>>>
>>> You don't know if it is defined or not? Makes no sense at all.
>>
>> That's correct.  [...]
>
> OK - glad we're on the same page :-D
>
>>>
>>> If, for each parameter, the dictionary gets a key entry with the value
>>> corresponding to the parameter name, then what is the value associated
>>> with that key. Referring again to the xample, what would be the value
>>> of x.searchParameters.title -- an Array?
>>
>> The value would be a string, such as "foo" or "bar".  In the example
>> you gave, there are two parameters with the name title.  The
>> specification will say which of the two values will show up in the
>> dictionary, but I haven't studied the question of which one yet.
>>
>
> That's just awful.
>
> A URI can have a parameter that appears more than once and it is very
> common case where they do. That is how checkboxes work -- multiple
> elements with same name, but different values. Same deal with
> select-multiple.
>
> [...]
>>
>
> That means I can't have "valueOf" as a query param. Or "__proto__",
> "toSource", etc.
>
>>
>> Rather than invent a new dictionary type, I think it make sense to use
>> the native one in the language (which in JavaScript is called Object),
>> which connects up with why modifying the dictionary doesn't mutate the
>> underlying URL.
>>
>
> Then say what you mean in that document. Object is not "Dictionary" If
> you mean Object, say it there.
>
> And I disagree. I think Dictionary is better. And while I'm at it,
> I'll make it LiveDictionary and borrow from Storage so it can use
> LiveDictionary too.
>
> LiveDictionary {
>  readonly attribute unsigned long length;
>  DOMString key(in unsigned long index);
>  any getItem(in DOMString key);
>  void setItem(in DOMString key, in any value);
>  void removeItem(in DOMString key);
>  void clear();
> }
>
> Even better than Storage. I've omitted the WebIDL's nonstandard, ECMA
> syntax extensions of "getter" which has no place being defined in
> WebIDL and should not be used until it is specified by ECMA (which may
> be never)).
>
>>> Working with parameter values can be a tricky if, say, the the program
>>> wants to remove one value for title and keep another. If URI has a
>>> getParameterMap then it should either be live or it should have a
>>> setParameterMap method. The one way API makes no sense.
>>
>> I don't think we need to tackle that problem in the first version.
>> HTML has a very nice way of constructing URLs with query parameters
>> called the form element.
>>
> So what? Your advice is for the client of the API to create a FORM
> element, create INPUT elements, then what?
>
> I'm not following the usage pattern.
>
> Garrett
>

Re: A URL API

[Garrett Smith]

On 9/17/10, Adam Barth  wrote:
> On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith 
> wrote:
>> On 9/17/10, Adam Barth  wrote:
>>> On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith 
>>> wrote:
 Where is Dictionary defined?
>>>
>>> It might not be defined yet.
>>
>> You don't know if it is defined or not? Makes no sense at all.
>
> That's correct.  [...]

OK - glad we're on the same page :-D

>>
>> If, for each parameter, the dictionary gets a key entry with the value
>> corresponding to the parameter name, then what is the value associated
>> with that key. Referring again to the xample, what would be the value
>> of x.searchParameters.title -- an Array?
>
> The value would be a string, such as "foo" or "bar".  In the example
> you gave, there are two parameters with the name title.  The
> specification will say which of the two values will show up in the
> dictionary, but I haven't studied the question of which one yet.
>

That's just awful.

A URI can have a parameter that appears more than once and it is very
common case where they do. That is how checkboxes work -- multiple
elements with same name, but different values. Same deal with
select-multiple.

[...]
>

That means I can't have "valueOf" as a query param. Or "__proto__",
"toSource", etc.

>
> Rather than invent a new dictionary type, I think it make sense to use
> the native one in the language (which in JavaScript is called Object),
> which connects up with why modifying the dictionary doesn't mutate the
> underlying URL.
>

Then say what you mean in that document. Object is not "Dictionary" If
you mean Object, say it there.

And I disagree. I think Dictionary is better. And while I'm at it,
I'll make it LiveDictionary and borrow from Storage so it can use
LiveDictionary too.

LiveDictionary {
  readonly attribute unsigned long length;
  DOMString key(in unsigned long index);
  any getItem(in DOMString key);
  void setItem(in DOMString key, in any value);
  void removeItem(in DOMString key);
  void clear();
}

Even better than Storage. I've omitted the WebIDL's nonstandard, ECMA
syntax extensions of "getter" which has no place being defined in
WebIDL and should not be used until it is specified by ECMA (which may
be never)).

>> Working with parameter values can be a tricky if, say, the the program
>> wants to remove one value for title and keep another. If URI has a
>> getParameterMap then it should either be live or it should have a
>> setParameterMap method. The one way API makes no sense.
>
> I don't think we need to tackle that problem in the first version.
> HTML has a very nice way of constructing URLs with query parameters
> called the form element.
>
So what? Your advice is for the client of the API to create a FORM
element, create INPUT elements, then what?

I'm not following the usage pattern.

Garrett

Re: A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 2:39 PM, Garrett Smith  wrote:
> On 9/17/10, Adam Barth  wrote:
>> On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith 
>> wrote:
>>> Where is Dictionary defined?
>>
>> It might not be defined yet.
>
> You don't know if it is defined or not? Makes no sense at all.

That's correct.  I wrote the word Dictionary there, and I had a clear
idea what I had in mind, but I'm not sure whether that idea has been
written down anywhere.

>>> What are the values for searchParameters
>>> -- can they be strings or are they only array;
>>
>> In JavaScript, I'd imagine implementing them as a normal JavaScript
>> object with property names that correspond to the URL parameters.
>>
>>> var x = new URL("http://example.net/?title=foo&title=bar);
>>> x.searchParameters.title;
>>>
>>> ?
>>
> SO you're saying that
>
> x.searchParameters.title is an object with property names that
> correspond to URL parameters -- again -- makes no sense. It looks like
> you didn't understand question so I'll rephrase and elaborate:
>
> If, for each parameter, the dictionary gets a key entry with the value
> corresponding to the parameter name, then what is the value associated
> with that key. Referring again to the xample, what would be the value
> of x.searchParameters.title -- an Array?

The value would be a string, such as "foo" or "bar".  In the example
you gave, there are two parameters with the name title.  The
specification will say which of the two values will show up in the
dictionary, but I haven't studied the question of which one yet.

> And what of the prototype of that Dictionary?

Object.prototype.

> Another object with nonstandard catchall behavior?

No.

> No thanks on that. What is the value of
> x.searchParameters.valueOf? undefined? A function? Null?

Object.prototype.valueOf

> Storage also has live-Dictionary features but does not use Dictionary.
> Seems like a common interface.
>
> 
>
> get/set/remove/clear all make sense there, but so do batch adds, e.g.
> setItems(obj).

Rather than invent a new dictionary type, I think it make sense to use
the native one in the language (which in JavaScript is called Object),
which connects up with why modifying the dictionary doesn't mutate the
underlying URL.

> Working with parameter values can be a tricky if, say, the the program
> wants to remove one value for title and keep another. If URI has a
> getParameterMap then it should either be live or it should have a
> setParameterMap method. The one way API makes no sense.

I don't think we need to tackle that problem in the first version.
HTML has a very nice way of constructing URLs with query parameters
called the form element.

Adam

Re: A URL API

[Garrett Smith]

On 9/17/10, Adam Barth  wrote:
> On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak  wrote:
>> On Sep 17, 2010, at 11:36 AM, Adam Barth wrote:
>>> On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher 
>>> wrote:
 On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
> Here's a sketch:
>
> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en

 Nice!  Is there any implicit unescaping done when reading those members?
  I'd hope for the answer to be "no" :-)
>>>
>>> That's a good question.  I'd expect them to just be textual segments
>>> of the URL so you could reconstruct the URL by concatenating them.
>>
>> That would be different behavior than what Location and HTMLAnchorElement
>> do; they unescape various componenents. Is the benefit worth the
>> divergence?
>
> It's probably worth being consistent even if it's slightly less
> desirable for authors.
>
>> As a side note, an out-of-document HTMLAnchorElement already provides most
>> of the functionality of this interface. Things it can't do:
>> - Resolve a relative URL against no base at all (probably not very useful
>> since the interface can only represent an absolute URL).
>> - Resolve against an arbitrary base (maybe you could do it awkwardly using
>>  tag tricks).
>> - Read or write the lastPathComponent or origin without further parsing
>> (should origin really be writable? That's kind of weird...)
>
> Making origin writeable seems to make about as much sense as making
> the protocol writable.  I'm not sure it's that useful, but I also
> don't see a reason to forbid it.
>
>> - Read search parameters conveniently without parsing.
>
> This is something I've often wanted when authoring HTML documents.
>
>> It might be nice to provide the parts of this that make sense on
>> HTMLAnchorElement and Location, then see if a new interface really pulls
>> its weight.
>
> Another piece of functionality that's missing from HTMLAnchorElement
> is the automatic stringification of URL objects.  That lets you pass
> URL objects into APIs that expect URLs represented as strings.  It's
> unlikely that we'd want to add that part of the interface to
> HTMLAnchorElement.
>
> On Fri, Sep 17, 2010 at 11:56 AM, Anne van Kesteren 
> wrote:
>> We have navigator.resolveURL(url) in HTML5. I believe that was mostly for
>> Web Workers. Probably because in Workers you cannot have stray 
>> elements,
>> or maybe because we just forgot about using ... (Not really been
>> involved
>> in that discussion.)
>
> Indeed.  Workers cannot have DOM elements, which means using a non-DOM
> object to parse URLs makes URL parsing functionality available to
> workers.  This combines especially well with the XMLHttpRequest use
> cases because XMLHttpRequest is a popular API for use in workers.
>
> On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith 
> wrote:
>> Where is Dictionary defined?
>
> It might not be defined yet.
>

You don't know if it is defined or not? Makes no sense at all.

>> What are the values for searchParameters
>> -- can they be strings or are they only array;
>
> In JavaScript, I'd imagine implementing them as a normal JavaScript
> object with property names that correspond to the URL parameters.
>
>> var x = new URL("http://example.net/?title=foo&title=bar);
>> x.searchParameters.title;
>>
>> ?
>
SO you're saying that

x.searchParameters.title is an object with property names that
correspond to URL parameters -- again -- makes no sense. It looks like
you didn't understand question so I'll rephrase and elaborate:

If, for each parameter, the dictionary gets a key entry with the value
corresponding to the parameter name, then what is the value associated
with that key. Referring again to the xample, what would be the value
of x.searchParameters.title -- an Array?

And what of the prototype of that Dictionary? Another object with
nonstandard catchall behavior? No thanks on that. What is the value of
x.searchParameters.valueOf? undefined? A function? Null?

Storage also has live-Dictionary features but does not use Dictionary.
Seems like a common interface.



get/set/remove/clear all make sense there, but so do batch adds, e.g.
setItems(obj).

Working with parameter values can be a tricky if, say, the the program
wants to remove one value for title and keep another. If URI has a
getParameterMap then it should either be live or it should have a
setParameterMap method. The one way API makes no sense.
-- 
Garrett

Re: A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak  wrote:
> On Sep 17, 2010, at 11:36 AM, Adam Barth wrote:
>> On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher  wrote:
>>> On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
 Here's a sketch:

 https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>>>
>>> Nice!  Is there any implicit unescaping done when reading those members?
>>>  I'd hope for the answer to be "no" :-)
>>
>> That's a good question.  I'd expect them to just be textual segments
>> of the URL so you could reconstruct the URL by concatenating them.
>
> That would be different behavior than what Location and HTMLAnchorElement do; 
> they unescape various componenents. Is the benefit worth the divergence?

It's probably worth being consistent even if it's slightly less
desirable for authors.

> As a side note, an out-of-document HTMLAnchorElement already provides most of 
> the functionality of this interface. Things it can't do:
> - Resolve a relative URL against no base at all (probably not very useful 
> since the interface can only represent an absolute URL).
> - Resolve against an arbitrary base (maybe you could do it awkwardly using 
>  tag tricks).
> - Read or write the lastPathComponent or origin without further parsing 
> (should origin really be writable? That's kind of weird...)

Making origin writeable seems to make about as much sense as making
the protocol writable.  I'm not sure it's that useful, but I also
don't see a reason to forbid it.

> - Read search parameters conveniently without parsing.

This is something I've often wanted when authoring HTML documents.

> It might be nice to provide the parts of this that make sense on 
> HTMLAnchorElement and Location, then see if a new interface really pulls its 
> weight.

Another piece of functionality that's missing from HTMLAnchorElement
is the automatic stringification of URL objects.  That lets you pass
URL objects into APIs that expect URLs represented as strings.  It's
unlikely that we'd want to add that part of the interface to
HTMLAnchorElement.

On Fri, Sep 17, 2010 at 11:56 AM, Anne van Kesteren  wrote:
> We have navigator.resolveURL(url) in HTML5. I believe that was mostly for
> Web Workers. Probably because in Workers you cannot have stray  elements,
> or maybe because we just forgot about using ... (Not really been involved
> in that discussion.)

Indeed.  Workers cannot have DOM elements, which means using a non-DOM
object to parse URLs makes URL parsing functionality available to
workers.  This combines especially well with the XMLHttpRequest use
cases because XMLHttpRequest is a popular API for use in workers.

On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith  wrote:
> Where is Dictionary defined?

It might not be defined yet.

> What are the values for searchParameters
> -- can they be strings or are they only array;

In JavaScript, I'd imagine implementing them as a normal JavaScript
object with property names that correspond to the URL parameters.

> var x = new URL("http://example.net/?title=foo&title=bar);
> x.searchParameters.title;
>
> ?

The specification will define which result we get.  We'll want to look
at other parameter parsing libraries to see if the first or last
occurrence of a parameter is the more popular semantics.

> What happens if the constructor is passed a url that is not
> well-formed or unparseable per http://tools.ietf.org/html/rfc3986?

You'll likely end up with a URL object with a lot of null values for
URL components.

> What about "javascript:" pseudo-protocol?

That should work fine.

> Why not make searchParams live? And why not make it so that
> x.searchParams.add("title", "bar"); modifies the entry for that?

I think it's more elegant if searchParameters is just a plain old dictionary.

> My 2007 ES4 proposal had more, e.g. setParameterMap,  which takes an
> object and sets values on the URI.
>
> x.setParameterMap({ name : "fee", val: 12, relatedPIDs : ["3aw34", "2345f"] })

I'm not sure that's worth doing in the first version.  If there's
sufficient demand, then we can add that in a future version.

> When are components percent-encoded?

Whenever you read from the object, you observe the canonicalized
version of the URL.

> Should "protocol" be named "scheme"? I'm aware that browsers have
> location.protocol pointing to the "scheme" though some schemes e.g.
> mailto, geo are not also protocols.

I chose the names to be consistent with the other parts of the
platform that name the parts of URLs.  These names are certainly not
ideal, but consistency seems more valuable than these distinctiosn.

Adam

Re: A URL API

[Anne van Kesteren]

On Fri, 17 Sep 2010 20:51:27 +0200, Maciej Stachowiak   
wrote:
That would be different behavior than what Location and  
HTMLAnchorElement do; they unescape various componenents. Is the benefit  
worth the divergence?


As a side note, an out-of-document HTMLAnchorElement already provides  
most of the functionality of this interface. Things it can't do:
- Resolve a relative URL against no base at all (probably not very  
useful since the interface can only represent an absolute URL).
- Resolve against an arbitrary base (maybe you could do it awkwardly  
using  tag tricks).


You could actually "just" use xml:base.


- Read or write the lastPathComponent or origin without further parsing  
(should origin really be writable? That's kind of weird...)

- Read search parameters conveniently without parsing.

It might be nice to provide the parts of this that make sense on  
HTMLAnchorElement and Location, then see if a new interface really pulls  
its weight.


We have navigator.resolveURL(url) in HTML5. I believe that was mostly for  
Web Workers. Probably because in Workers you cannot have stray   
elements, or maybe because we just forgot about using ... (Not really  
been involved in that discussion.)



--
Anne van Kesteren
http://annevankesteren.nl/

Re: A URL API

[Maciej Stachowiak]

On Sep 17, 2010, at 11:36 AM, Adam Barth wrote:

> On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher  wrote:
>> On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
>>> On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
 On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher 
 wrote:
> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
> wrote:
>> That sounds good to me. In general I think it would be great if there
>> were
>> standard APIs for URI/IRI construction, parsing and resolution...
> 
> Yes, that sounds pretty good to me too.
 
 This has annoyed me for a while too.  I'll write up a spec.
>>> 
>>> Here's a sketch:
>>> 
>>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>> 
>> Nice!  Is there any implicit unescaping done when reading those members?
>>  I'd hope for the answer to be "no" :-)
> 
> That's a good question.  I'd expect them to just be textual segments
> of the URL so you could reconstruct the URL by concatenating them.

That would be different behavior than what Location and HTMLAnchorElement do; 
they unescape various componenents. Is the benefit worth the divergence?

As a side note, an out-of-document HTMLAnchorElement already provides most of 
the functionality of this interface. Things it can't do:
- Resolve a relative URL against no base at all (probably not very useful since 
the interface can only represent an absolute URL).
- Resolve against an arbitrary base (maybe you could do it awkwardly using 
 tag tricks).
- Read or write the lastPathComponent or origin without further parsing (should 
origin really be writable? That's kind of weird...)
- Read search parameters conveniently without parsing.

It might be nice to provide the parts of this that make sense on 
HTMLAnchorElement and Location, then see if a new interface really pulls its 
weight.

Regards,
Maciej

Re: A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher  wrote:
> On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:
>> On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
>> > On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher 
>> > wrote:
>> >> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
>> >> wrote:
>> >>> That sounds good to me. In general I think it would be great if there
>> >>> were
>> >>> standard APIs for URI/IRI construction, parsing and resolution...
>> >>
>> >> Yes, that sounds pretty good to me too.
>> >
>> > This has annoyed me for a while too.  I'll write up a spec.
>>
>> Here's a sketch:
>>
>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>
> Nice!  Is there any implicit unescaping done when reading those members?
>  I'd hope for the answer to be "no" :-)

That's a good question.  I'd expect them to just be textual segments
of the URL so you could reconstruct the URL by concatenating them.

> When does canonicalization happen?  Only when you call href?  Or, does it
> happen when you readback any attribute?

I think it should happen when you read back any attribute.  That seems
safest from a security perspective since you're aways reading back
something canonical.

On Fri, Sep 17, 2010 at 11:16 AM, Nathan  wrote:
> might I suggest naming it URI or IRI, and the addition of some or all of the
> following methods:

I'd like to avoid bikeshedding about the name at this time.  We can
certainly discuss that in the future.

>  bool isAbsolute();
>  URI toAbsolute();

The interface will always represent an absolute URL.

>  URI defrag();

What does this mean?  If you mean "remove the fragment," you can do
that by assigning null to the hash property.

>  URI resolveReference(in URI reference);

You can do this with the constructor:

var resolved_url = new URL(relative_url, base_url);

> the following methods exposed to handle complicated URIs:
>
>  u = new URI('http://ex.org/a/b/c/d/../.././egg#s/../x');
>  u.isAbsolute();                        -> boolean
>  u.defrag();                            ->
> 'http://ex.org/a/b/c/d/../.././egg'
>  u.toAbsolute();                        -> 'http://ex.org/a/b/egg'
>
> and to resolve relative URIs + URI References:
>
>  u = new URI('http://ex.org/a/b/c/d');
>  u.resolveReference('../.././n?x=y');   -> 'http://ex.org/a/n?x=y'
>
> ps: I'll happily implement this interface Javascript whenever as I've
> already got something similar: http://github.com/webr3/URI

Thanks.  It would certainly be helpful to have a sample implementation
in JavaScript.

Adam

Re: A URL API

[Nathan]

Adam Barth wrote:

On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:

On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher  wrote:

On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
wrote:

That sounds good to me. In general I think it would be great if there were
standard APIs for URI/IRI construction, parsing and resolution...

Yes, that sounds pretty good to me too.

This has annoyed me for a while too.  I'll write up a spec.


Here's a sketch:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en


might I suggest naming it URI or IRI, and the addition of some or all of 
the following methods:

  bool isAbsolute();
  URI defrag();
  URI toAbsolute();
  URI resolveReference(in URI reference);

the following methods exposed to handle complicated URIs:

  u = new URI('http://ex.org/a/b/c/d/../.././egg#s/../x');
  u.isAbsolute();-> boolean
  u.defrag();-> 
'http://ex.org/a/b/c/d/../.././egg'

  u.toAbsolute();-> 'http://ex.org/a/b/egg'

and to resolve relative URIs + URI References:

  u = new URI('http://ex.org/a/b/c/d');
  u.resolveReference('../.././n?x=y');   -> 'http://ex.org/a/n?x=y'

ps: I'll happily implement this interface Javascript whenever as I've 
already got something similar: http://github.com/webr3/URI


Best,

Nathan

Re: A URL API

[Darin Fisher]

On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth  wrote:

> On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
> > On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher 
> wrote:
> >> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
> >> wrote:
> >>> That sounds good to me. In general I think it would be great if there
> were
> >>> standard APIs for URI/IRI construction, parsing and resolution...
> >>
> >> Yes, that sounds pretty good to me too.
> >
> > This has annoyed me for a while too.  I'll write up a spec.
>
> Here's a sketch:
>
>
> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>
> Adam
>

Nice!  Is there any implicit unescaping done when reading those members?
 I'd hope for the answer to be "no" :-)

When does canonicalization happen?  Only when you call href?  Or, does it
happen when you readback any attribute?

-Darin

A URL API

[Adam Barth]

On Fri, Sep 17, 2010 at 10:27 AM, Adam Barth  wrote:
> On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisher  wrote:
>> On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschke 
>> wrote:
>>> That sounds good to me. In general I think it would be great if there were
>>> standard APIs for URI/IRI construction, parsing and resolution...
>>
>> Yes, that sounds pretty good to me too.
>
> This has annoyed me for a while too.  I'll write up a spec.

Here's a sketch:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en

Adam