Re: A URL API
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.comwrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
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 da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
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 dev.akh...@gmail.com 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 da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
+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 w...@adambarth.com 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 dev.akh...@gmail.com 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 da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
How about setParameter(name, value...) that takes var_args number of values? Alternately, it could take either a DOMString or an ArrayDOMString 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 w...@adambarth.com 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 dev.akh...@gmail.com 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 da...@chromium.org wrote: On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote:
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an ArrayDOMString 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 w...@adambarth.com 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 dev.akh...@gmail.com
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 da...@chromium.org wrote:
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith
dhtmlkitc...@gmail.com
wrote:
On 9/20/10, Julian Reschke julian.resc...@gmx.de 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
On Tue, Sep 21, 2010 at 12:51 AM, Devdatta Akhawe dev.akh...@gmail.com wrote:
On 21 September 2010 00:47, Ojan Vafai o...@chromium.org wrote:
How about setParameter(name, value...) that takes var_args number of values?
Alternately, it could take either a DOMString or an ArrayDOMString 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
On 9/21/10, Ojan Vafai o...@chromium.org wrote: How about setParameter(name, value...) that takes var_args number of values? Alternately, it could take either a DOMString or an ArrayDOMString 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: [CORS] HTTP error codes in preflight response
On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking jo...@sicking.cc wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it seems somewhat strange to me to do this with responses to the preflight OPTIONS request. If a OPTIONS request results in a 404, then it seems to me that the request can not be considered successful, and that access to place the real request should not be granted. Otherwise we are essentially ignoring the status code and not exposing it anywhere, which seems strange. So preflight requests should only succeed if the status code of the response is 200, correct? All other status codes mean failure? (Not counting 1xx here, as they are transport codes, not response codes.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [CORS] HTTP error codes in preflight response
Anne van Kesteren wrote: On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking jo...@sicking.cc wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it seems somewhat strange to me to do this with responses to the preflight OPTIONS request. If a OPTIONS request results in a 404, then it seems to me that the request can not be considered successful, and that access to place the real request should not be granted. Otherwise we are essentially ignoring the status code and not exposing it anywhere, which seems strange. So preflight requests should only succeed if the status code of the response is 200, correct? All other status codes mean failure? (Not counting 1xx here, as they are transport codes, not response codes.) does the response to a pre-flight have a message body? if not would 204 No Content be suited for success and 4xx/5xx for failure. How are 3xx being handled, if the response is a 3xx then does it still require preflight additional request just to then repeat on another URL? Best, Nathan
Re: A URL API
On Mon, Sep 20, 2010 at 11:02 AM, Garrett Smith dhtmlkitc...@gmail.com 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: [CORS] HTTP error codes in preflight response
On 21.09.2010 11:04, Anne van Kesteren wrote: On Tue, 21 Sep 2010 02:05:10 +0200, Jonas Sicking jo...@sicking.cc wrote: CORS was recently clarified to say that error responses, such as 4xx/5xx responses, should not abort the various algorithms but instead such a response should be forwarded to, for example, the XMLHttpRequest implementation. However it seems somewhat strange to me to do this with responses to the preflight OPTIONS request. If a OPTIONS request results in a 404, then it seems to me that the request can not be considered successful, and that access to place the real request should not be granted. Otherwise we are essentially ignoring the status code and not exposing it anywhere, which seems strange. So preflight requests should only succeed if the status code of the response is 200, correct? All other status codes mean failure? (Not counting 1xx here, as they are transport codes, not response codes.) All 2xx codes are success codes. Best regards, Julian
Re: [CORS] HTTP error codes in preflight response
On Tue, 21 Sep 2010 11:44:46 +0200, Julian Reschke julian.resc...@gmx.de wrote: All 2xx codes are success codes. Sure, but the others make no sense in this context and simply checking for 200 is easier than checking for a range. -- Anne van Kesteren http://annevankesteren.nl/
Re: [CORS] HTTP error codes in preflight response
On 21.09.2010 11:48, Anne van Kesteren wrote: On Tue, 21 Sep 2010 11:44:46 +0200, Julian Reschke julian.resc...@gmx.de wrote: All 2xx codes are success codes. Sure, but the others make no sense in this context and simply checking for 200 is easier than checking for a range. How do you know now that 234 will not make sense in two years from now? Best regards, Julian
Re: [CORS] HTTP error codes in preflight response
On 21.09.2010 11:58, Anne van Kesteren wrote: On Tue, 21 Sep 2010 11:53:39 +0200, Julian Reschke julian.resc...@gmx.de wrote: How do you know now that 234 will not make sense in two years from now? Common sense. But apart from that it seems saner to just operate from a whitelist here. We only need one response code for the protocol to work -- 200 -- why make it unbounded? To address use case we currently don't know of. Remember, extensibility. Best regards, Julian
Re: [CORS] HTTP error codes in preflight response
On Tue, 21 Sep 2010 12:04:44 +0200, Julian Reschke julian.resc...@gmx.de wrote: To address use case we currently don't know of. Remember, extensibility. We can easily allow more status codes when the use cases exists. That would also be better in case client updates are required. -- Anne van Kesteren http://annevankesteren.nl/
Re: A URL API
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 object element with child param 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 Barthw...@adambarth.com wrote: On Thu, Sep 16, 2010 at 3:25 PM, Darin Fisherda...@chromium.org wrote: On Thu, Sep 16, 2010 at 6:31 AM, Julian Reschkejulian.resc...@gmx.de 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-t7lZgzisTuGTXkdzAk4gLUhl=en Adam
Re: A URL API
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=ax=bx=c I am fine with this. cheers devdatta Adam
Re: A URL API
On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com 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: Widgets - WARP, Widgets Updates and Digital Signatures
Hi - just wanted to note that Mozilla Labs people are here and listening. There are people in the labs group that are very interested in web application deployment into the main browser context. We are not particularly focused on widgets per se (as has been noted there are many runtimes for those, including Mozilla-platform-derived ones), but we have noted the trend of full-browser-window applications and are thinking about what it means. Claes' note of Sep 10 [1], summarized the questions that we're thinking about nicely. I would say that our current leaning is towards the HTML5 feature stack, with AppCache, local storage/indexedDB, and CORS/postMessage playing prominent roles. My current feeling is that widgets that are stored forever are better suited for a widget runtime than a general browser. That suggests that packaging will play a smaller role on the browser UA since we will largely be working with manifests. API and network access permissioning at install time makes a lot of sense, as does integration with UX elements that help users manage a multi-application environment (pinned tabs, notifications, etc.). I have a personal interest in identity systems and would also like to see whether we can simplify application-identity management at this level. Marcos - the Widget Landscape document [2] identifies the difference between Widget user agents and general browsers - but would you highlight any of the widget specs as solving as-yet-untackled problems in the general-browser application space? [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/0049.html [2] http://www.w3.org/TR/widgets-land/ -Michael -- Michael Hanson, Mozilla Labs (@michaelrhanson) On Sep 16, 2010, at 5:30 PM, Marcos Caceres wrote: Hi Nathan, On 9/16/10 7:38 PM, Nathan wrote: Marcos Caceres wrote: On 9/16/10 6:10 PM, Nathan wrote: Marcos Caceres wrote: As above. I thought that was what we (Web Apps WG - Widgets) have been doing for the last 5 years? Maybe I've missed part of the specifications - are you telling me that I can package up an HTML,CSS,JS based application as per the widgets specification, include a WARP, Digital Signature, set the view-mode to windowed and that this will run as is, in the main browser context of the main browser vendors (Firefox, Safari, Opera, Chrome, IE etc)? Ah! ok. I get it now. No, that won't work right now (actually, that's how we run them in our development environment for testing purposes :) ). But that is trivial and no one has really asked for that. snip Everything is currently pointing at an exponential increase in 100% client side applications, from all angles, we've got client side persistence, html5, canvas, ecmascript, gpu acceleration, a vast web of data, cloud storage, positioning the web as the data tier, a plethora of standardized and supported APIs + media types - every element. Right. It's all looking pretty sweet... maybe we don't need them widgets things after all...:) The missing bit to tie it all together is for somebody to simply say here's how you wrap it all up and deploy, and that work has been all but done under the banner of the widgets specifications. Opera supports W3C widgets: use that :) For Webkit and friends, they are open source, maybe you can just hack the support and convince them to make it a standard part of their platform. Other people have done this (e.g., Widgeon runs on Mozilla's code, and there are lots of WebKit implementations of widgets). You can also email Apple and Mozilla and ask them to add support widgets if you think its important. I'd be interested to hear what they say - I'm sure they would be receptive to the idea.
Re: A URL API
appendParameter/clearParameter seems fine to me. On Wed, Sep 22, 2010 at 2:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Sep 20, 2010 at 11:56 PM, Adam Barth w...@adambarth.com 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
