Re: [XHR2] Disable new response types for sync XHR in Window context
On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes, I think cross-origin should not work with sync. That is currently the only synchronous communication mechanism cross origin. Without it a UA could put up UI if it wants to explicitly allow users to control such communication. Eww. But you agree with my suggestion about exceptions? I can put that in the specification and push to get it implemented in Opera, but it would help if you said you agreed with the specifics to avoid surprises down the road. -- Anne van Kesteren http://annevankesteren.nl/
Re: Is BlobBuilder needed?
Jonas Sicking wrote: Hi everyone, It was pointed out to me on twitter that BlobBuilder can be replaced with simply making Blob constructable. I.e. the following code: var bb = new BlobBuilder(); bb.append(blob1); bb.append(blob2); bb.append(some string); bb.append(myArrayBuffer); var b = bb.getBlob(); would become b = new Blob([blob1, blob2, some string, myArrayBuffer]); or look at it another way: var x = new BlobBuilder(); becomes var x = []; x.append(y); becomes x.push(y); var b = x.getBlob(); becomes var b = new Blob(x); So at worst there is a one-to-one mapping in code required to simply have |new Blob|. At best it requires much fewer lines if the page has several parts available at once. And we'd save a whole class since Blobs already exist. Following the previous discussion (which seemed to raise no major objections) can we expect to see this in the File API spec sometime soon (assuming that spec is the right home for this)? This will require a coordinated edit to coincide with the removal of BlobBuilder from the File Writer API, right? Thanks, Rich / Jonas
Re: QSA, the problem with :scope, and naming
Right now, the spec does however handle that use case by doing this: document.querySelectorAll(:scope .foo, x); Where x is either an individual element, or an Array, NodeList or numerically indexed object containing 0 or more Elements. (It does however limit the result only to elements that are in the document, and any disconnected elements in the collection x would not be found.) What spec are you referring to? I've never seen that and I am having trouble finding it now.
Re: QSA, the problem with :scope, and naming
On 2011-11-15 15:13, Brian Kardell wrote: Right now, the spec does however handle that use case by doing this: document.querySelectorAll(:scope .foo, x); Where x is either an individual element, or an Array, NodeList or numerically indexed object containing 0 or more Elements. (It does however limit the result only to elements that are in the document, and any disconnected elements in the collection x would not be found.) What spec are you referring to? I've never seen that and I am having trouble finding it now. It's in the draft of Selectors API Level 2. http://dev.w3.org/2006/webapi/selectors-api2/#nodeselector See the refElement/refNodes parameters which specify elements matched by :scope. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Is BlobBuilder needed?
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking jo...@sicking.cc wrote:
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
I noticed this at https://developer.mozilla.org/en/Firefox_8_for_developers:
BlobBuilder now has a getFile() method that returns the content of the
blob as a file.
This suggests a File constructor as well, eg. b = new File([foo, bar], {
name: file.jpg });.
(Of course, the only difference is that the created object has the File
interface, with an attached filename. It would make no difference to how
the data is stored, which isn't actually tied to the interface.)
--
Glenn Maynard
Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 10:55 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking jo...@sicking.cc wrote:
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
I noticed this at
https://developer.mozilla.org/en/Firefox_8_for_developers:
BlobBuilder now has a getFile() method that returns the content of the
blob as a file.
This suggests a File constructor as well, eg. b = new File([foo, bar], {
name: file.jpg });.
(Of course, the only difference is that the created object has the File
interface, with an attached filename. It would make no difference to how
the data is stored, which isn't actually tied to the interface.)
I think we decided that we're going to remove getFile. See
https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later.
- Kyle
Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 11:04 AM, Kyle Huey m...@kylehuey.com wrote: I think we decided that we're going to remove getFile. See https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later. FWIW, although I won't argue strongly for it here (we can always come back to it), I don't think there are any strong arguments against being able to create Files in there. You don't need a real file on a filesystem in order to expose file metadata in File (it's just an interface), and having objects with the File interface always backed by a filesystem file doesn't seem like a very meaningful distinction. -- Glenn Maynard
Re: Is BlobBuilder needed?
On Tue, Nov 15, 2011 at 5:41 AM, Rich Tibbett ri...@opera.com wrote: Jonas Sicking wrote: Hi everyone, It was pointed out to me on twitter that BlobBuilder can be replaced with simply making Blob constructable. I.e. the following code: var bb = new BlobBuilder(); bb.append(blob1); bb.append(blob2); bb.append(some string); bb.append(myArrayBuffer); var b = bb.getBlob(); would become b = new Blob([blob1, blob2, some string, myArrayBuffer]); or look at it another way: var x = new BlobBuilder(); becomes var x = []; x.append(y); becomes x.push(y); var b = x.getBlob(); becomes var b = new Blob(x); So at worst there is a one-to-one mapping in code required to simply have |new Blob|. At best it requires much fewer lines if the page has several parts available at once. And we'd save a whole class since Blobs already exist. Following the previous discussion (which seemed to raise no major objections) can we expect to see this in the File API spec sometime soon (assuming that spec is the right home for this)? This will require a coordinated edit to coincide with the removal of BlobBuilder from the File Writer API, right? It need not be all that coordinated. I can take it out [well...mark it deprecated, pending implementation changes] any time after the Blob constructor goes into the File API. Thanks, Rich / Jonas
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchard ch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
RE: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
James wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). Is it possible to get your UCs published somewhere? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: [XHR2] Disable new response types for sync XHR in Window context
On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sicking jo...@sicking.cc wrote: Yes, I think cross-origin should not work with sync. That is currently the only synchronous communication mechanism cross origin. Without it a UA could put up UI if it wants to explicitly allow users to control such communication. Eww. But you agree with my suggestion about exceptions? I can put that in the specification and push to get it implemented in Opera, but it would help if you said you agreed with the specifics to avoid surprises down the road. So if I understand the proposal correctly: After .open has been called with async=false: * setting .responseType to anything other than throws InvalidAccessError * setting .wirthCredentials to true throws InvalidAccessError Additionally, when calling .open with async=false, throw InvalidAccessError if .responseType is set to anything other than or .withCredentials is true. If that's the proposal, then this sounds good to me. / Jonas
Re: [XHR2] Disable new response types for sync XHR in Window context
On 11/15/2011 09:33 PM, Jonas Sicking wrote: On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sickingjo...@sicking.cc wrote: Yes, I think cross-origin should not work with sync. That is currently the only synchronous communication mechanism cross origin. Without it a UA could put up UI if it wants to explicitly allow users to control such communication. Eww. But you agree with my suggestion about exceptions? I can put that in the specification and push to get it implemented in Opera, but it would help if you said you agreed with the specifics to avoid surprises down the road. So if I understand the proposal correctly: After .open has been called with async=false: * setting .responseType to anything other than throws InvalidAccessError * setting .wirthCredentials to true throws InvalidAccessError Additionally, when calling .open with async=false, throw InvalidAccessError if .responseType is set to anything other than or .withCredentials is true. If that's the proposal, then this sounds good to me. Sounds good to me to. Also, if xhr is sync, accessing .response or responseType could throw / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype We could say that the clone created when storing in the database is created in a separate global scope. / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
http://usecases.webintents.org/ Though admittedly it's not complete, and we need to update the site with a list of use cases we've rejected. On Tue, Nov 15, 2011 at 11:30 AM, Josh Soref jso...@rim.com wrote: James wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). Is it possible to get your UCs published somewhere? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
Since we don't have background intents (many reasons why, though we looked into the idea), the service is responsible for displaying progress UI for this use case. For example imagine the service is Dropbox: the client initiates the upload action and Dropbox is selected as the service by the user. Likely Dropbox will use an inline disposition. The picker will be open showing the service until the operation is complete. Dropbox should show the upload progress UI in their UI in this case. Does that work in your mind? I'm not attempting to put the kibosh on this line of thought; I'm very open to any use cases where progression notifications to the client are necessary for a good UX. James On Tue, Nov 15, 2011 at 11:15 AM, Charles Pritchard ch...@jumis.com wrote: I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
This is the way that I have implemented it in test apps. It is the handler app that will show the progress information. I have not had a case yet where the client app needs or is concerned about the progress of the action that is being handled, other than on completion or on error. I will launch a whole lot of new demo's soon so that we can all see them. P On Tue, Nov 15, 2011 at 9:37 PM, Charles Pritchard ch...@jumis.com wrote: Yes, that works in my mind. -Charles On 11/15/11 12:36 PM, James Hawkins wrote: Since we don't have background intents (many reasons why, though we looked into the idea), the service is responsible for displaying progress UI for this use case. For example imagine the service is Dropbox: the client initiates the upload action and Dropbox is selected as the service by the user. Likely Dropbox will use an inline disposition. The picker will be open showing the service until the operation is complete. Dropbox should show the upload progress UI in their UI in this case. Does that work in your mind? I'm not attempting to put the kibosh on this line of thought; I'm very open to any use cases where progression notifications to the client are necessary for a good UX. James On Tue, Nov 15, 2011 at 11:15 AM, Charles Pritchardch...@jumis.com wrote: I may be misunderstanding things, but I was thinking that saving a file to the cloud. FileSaver and XHR have onprogress events so users don't wonder too-much about large file uploads. Those are the only cases I was thinking of. -Charles On 11/15/2011 10:31 AM, James Hawkins wrote: A bit of back story: when designing and iterating the API, we focused heavily on use cases. We were unable to come up with a compelling (enough) use case for handling progress notifications, though the use cases we did have allowed us to think of ways to modify the API to support those use cases (not added to the current API). What use cases are you envisioning will require progress events? Thanks, James On Mon, Nov 14, 2011 at 7:30 PM, Charles Pritchardch...@jumis.com wrote: So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/**eventsource/http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchardch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox. -- Paul Kinlan Developer Advocate @ Google for Chrome and HTML5 G+: http://plus.ly/paul.kinlan t: +447730517944 tw: @Paul_Kinlan LinkedIn: http://uk.linkedin.com/in/paulkinlan Blog: http://paul.kinlan.me Skype: paul.kinlan
Re: [XHR2] Disable new response types for sync XHR in Window context
On Tue, Nov 15, 2011 at 11:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 11/15/2011 09:33 PM, Jonas Sicking wrote: On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sickingjo...@sicking.cc wrote: Yes, I think cross-origin should not work with sync. That is currently the only synchronous communication mechanism cross origin. Without it a UA could put up UI if it wants to explicitly allow users to control such communication. Eww. But you agree with my suggestion about exceptions? I can put that in the specification and push to get it implemented in Opera, but it would help if you said you agreed with the specifics to avoid surprises down the road. So if I understand the proposal correctly: After .open has been called with async=false: * setting .responseType to anything other than throws InvalidAccessError * setting .wirthCredentials to true throws InvalidAccessError Additionally, when calling .open with async=false, throw InvalidAccessError if .responseType is set to anything other than or .withCredentials is true. If that's the proposal, then this sounds good to me. Sounds good to me to. Also, if xhr is sync, accessing .response or responseType could throw I'm not sure that that buys us anything, and will just cause more code in implementations. / Jonas
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). / Jonas
TAG Comment on
This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
TAG Comment on Web Storage
Sorry I messed up the subject of the first copy of this note. (I was checking to make sure I got the title of the working draft right, put it in the body of the note, and forgot the subject line). Please accept my apologies...the risks of working in a hurry while running out the door. Noah On 11/15/2011 5:05 PM, Noah Mendelsohn wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). In terms of the behavior we care about they're the same. In terms of finely specifying how we evaluate keypaths: String values and String objects are different beasts, e.g. length in [1,2,3] -- true, length in abc -- TypeError, length in new String(abc) -- true. It turns out that abc.length is short for Object(abc).length which in turn is (new String(abc)).length which is really (new String(abc))[length]. So putting on the pedantic hat, string doesn't have any properties, it just behaves like it does c/o the fine grained rules of the [] operation in ECMAScript. Wheee.
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 2:20 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote: I do however think that we should simply state that getting the index values will use the normal method for looking up properties on JS objects. This includes walking the prototype chain. Practically speaking this only makes a difference on host objects like Files and ArrayBuffers since plain JS objects loose their prototype during structured clones. Since I lurk on es-discuss, I have to nitpick that this leaves spec ambiguity around Object.prototype and async operations. The HTML5 spec sayeth re: structured cloning of objects: Let output be a newly constructed empty Object object - that implies (to me) that the clone's prototype is Object.prototype. Here's where the ambiguity comes in - assume async API usage: my_store.createIndex(some index, foo); ... Object.prototype.foo = 1; my_store.put(new Object); Object.prototype.foo = 2; // what indexkey was used? One possibility would be to modify the structured clone algorithm (!) to mandate that the Object has no prototype (i.e. what you get from Object.create(null)) but that would probably surprise developers since the resulting objects wouldn't have toString() and friends. Scoped to just IDB we could explicitly exclude Object.prototype I don't think we want to say that structured clones create objects without a prototype since when you read objects out of the database we use structured clone, and there we definitely want to create objects which use the page's normal Object.prototype/Array.prototype/File.prototype Totally agree, that suggestion was a true straw-man intended to be burned. We could say that the clone created when storing in the database is created in a separate global scope. Very nice - I think that captures the semantics we want (namely, that script should not be able to distinguish whether implementations are operating on a serialized form or a live object.) This would imply that you can index on the special length property of Arrays, which seems useful. How about length of String instances (which is spec'd slightly differently)? I think those are the only two relevant special properties. Good point. How is string.length different from [].length? (Other than that strings are immutable and so never change their length). In terms of the behavior we care about they're the same. In terms of finely specifying how we evaluate keypaths: String values and String objects are different beasts, e.g. length in [1,2,3] -- true, length in abc -- TypeError, length in new String(abc) -- true. It turns out that abc.length is short for Object(abc).length which in turn is (new String(abc)).length which is really (new String(abc))[length]. So putting on the pedantic hat, string doesn't have any properties, it just behaves like it does c/o the fine grained rules of the [] operation in ECMAScript. Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length / Jonas
Re: TAG Comment on
Could you quantify widely? On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohn n...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: TAG Comment on
But we should give it a try, no? The spec are still Working Drafts. All the best, Ashok On 11/15/2011 2:47 PM, Adam Barth wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohnn...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: TAG Comment on
Chromium devs put forward a unified quota API recently. localStorage provides 5 megs of UTF16 storage; or about 2 megs of storage for binary files saved as base64 strings. It's terrible for that use. appCache had some Apis in existing proposals for programatically adding items. I don't know if vendors have been interested in implementing them. https://developer.mozilla.org/en/nsIDOMOfflineResourceList I've certainly wanted a simple key-val blob store. We still don't have one. Even a means to persist Blob Uris would be an improvement. On Nov 15, 2011, at 2:05 PM, Noah Mendelsohn n...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
RE: TAG Comment on
From: ext Glenn Adams [gl...@skynav.com] Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.commailto:w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility.
Re: [indexeddb] Keypath attribute lookup question
On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. Those are on the Number object itself, not Number.prototype and hence not inherited by instances of Number, so you can't do (1).NEGATIVE_INFINITY. You can't structured-clone Number itself (it's a function); you probably could structured-clone Math, but the behavior would be predictable (either the properties would clone or they wouldn't, but the resulting object would be distinct from the global Math object itself). It's just the sections Properties of XXX Instances and Properties of the XXX Prototype Object that we need to worry about. The others are functions - while these would exist in the theoretical new global context, they aren't valid keys. So I think the Array and String length properties are the only interesting cases. Good point, i missed the fact that the properties are on Number and not on Number. So even defining it as a plan property lookup would give the same behavior as below. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length That would certainly make conformance testing a lot easier. +1 from me. Sounds good. / Jonas
RE: [indexeddb] Keypath attribute lookup question
On Tuesday, November 15, 2011 4:33 PM, Jonas Sicking wrote: On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote: On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote: Hmm.. good point. Looking at the documentation for the built-in types, there are unfortunately also a host of constant properties on implicit Number objects. But I'm not convinced that you should be able to index on somenumberProp.NEGATIVE_INFINITY. Those are on the Number object itself, not Number.prototype and hence not inherited by instances of Number, so you can't do (1).NEGATIVE_INFINITY. You can't structured-clone Number itself (it's a function); you probably could structured-clone Math, but the behavior would be predictable (either the properties would clone or they wouldn't, but the resulting object would be distinct from the global Math object itself). It's just the sections Properties of XXX Instances and Properties of the XXX Prototype Object that we need to worry about. The others are functions - while these would exist in the theoretical new global context, they aren't valid keys. So I think the Array and String length properties are the only interesting cases. Good point, i missed the fact that the properties are on Number and not on Number. So even defining it as a plan property lookup would give the same behavior as below. How about we say that key-paths can only access properties explicitly copied by the structured clone algorithm plus the following: Blob.size Blob.type File.name File.lastModifiedDate Array.length String.length That would certainly make conformance testing a lot easier. +1 from me. Sounds good. This is the outcome we were hoping for. Do we need to add anything to the IDB spec to capture this behavior or is already covered (perhaps a note)? Israel / Jonas
Re: TAG Comment on
Extend, not delete. On Nov 15, 2011, at 3:51 PM, ashok malhotra ashok.malho...@oracle.com wrote: But we should give it a try, no? The spec are still Working Drafts. All the best, Ashok On 11/15/2011 2:47 PM, Adam Barth wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility. Adam On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohnn...@arcanedomain.com wrote: This is a comment from the W3C Technical Architecture Group on the last call working draft: Web Storage [1]. The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both provide client-side storage that can be used by Web Applications. Although the interfaces are different (AppCache has an HTML interface while Local Storage has a JavaScript API), and they do seem to have been designed with different use cases in mind, they provide somewhat related facilities: both cause persistent storage for an application to be created, accessed and managed locally at the client. If, for example, the keys in Local Storage were interpreted as URIs then Local Storage could be used to store manifest files and Web Applications could be written to look transparently for manifest files in either the AppCache or in Local Storage. One might also envision common facilities for querying the size of or releasing all of the local storage for a given application. At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a request for a JavaScript API for AppCache and talk about coordinating AppCache and Local Storage. The TAG believes it is important to consider more carefully the potential advantages of providing a single facility to cover the use cases, of perhaps modularizing the architecture so that some parts are shared, or if separate facilities are indeed the best design, providing common data access and manipulation APIs. If further careful analysis suggests that no such integration is practical, then, at a minimum, each specification should discuss how it is positioned with respect to the other. Noah Mendelsohn For the: W3C Technical Architecture Group [1] http://www.w3.org/TR/2011/WD-webstorage-20111025/ [2] http://www.w3.org/TR/html5/offline.html#appcache [3] http://www.w3.org/2011/web-apps-ws/
Re: TAG Comment on
Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. On Tue, Nov 15, 2011 at 5:21 PM, art.bars...@nokia.com wrote: * From:* ext Glenn Adams [gl...@skynav.com] * * Could you quantify widely? I think this definition of widely used is useful for this context: http://caniuse.com/#search=storage Personally, I see little to negative value in ignoring the fact the ship has sailed for this spec. -AB On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com wrote: These APIs are quite widely used on the web. It seems unlikely that we'll be able to delete either of them in favor of a single facility.
Re: TAG Comment on
On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@skynav.com wrote: Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. Use of a feature does, in fact, imply that, unless there are *very* good reasons why not. Specs and implementations advance together, and both constrain the other. ~TJ
Re: TAG Comment on
* Tab Atkins Jr. wrote: On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@skynav.com wrote: Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. Use of a feature does, in fact, imply that, unless there are *very* good reasons why not. Specs and implementations advance together, and both constrain the other. Well, they advance from Working Draft to Working Draft and then it's too late to make changes before there is a Call for Implementations as the implementations have already been shipping for years. The Last Call is meant to avoid that, providing an opportunity to build a consensus even with people and organizations that cannot follow the day-to-day working group and implementation progress to prioritize their reviews. Which the Last Calls relevant to this thread obviously do not provide. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: TAG Comment on
Speaking for myself now, and not necessarily for the TAG: I agree with those who say or imply that it's late for making incompatible changes to the Web Storage specification. I'm less clear that's the case for appcache, given comments about its many problems at the workshop last week, but just for purposes of this email let's assume that it too might be too widely deployed to change wholesale. I also think the TAG is right to ask that the relationship between the two be considered more carefully than, as far as I know it has been. There are many dimensions in which one could imagine innovating to improve the synergies without necessarily disrupting existing deployments. To pick one example signaled in the TAG's email, I would think that one could innovate with application management (e.g. install/uninstall) and space management (query space used by application, set quotas, etc.) that could be done in ways that are compatible with the existing specs. Maybe or maybe not it would be beneficial to integrate them further, e.g. by providing a standard means for storing app-cached resources in Web Storage or otherwise integrating what are now disparate clumps of application data. Whether these will prove to be good things to do is TBD, but I agree with the rest of the TAG that doing the work to find out is important. I also think there are many potentially useful changes that could be made without inappropriate disruption to early deployments. FWIW: I would rather not debate here the difficult balance, in general, between deploying early enough to get real user feedback before specs are frozen, and then finding that you can't actually change the specs based on that experience, because deployment is too widespread. That's a very important debate, but for this thread, I would rather just concentrate on seeing what's practical and beneficial with respect to application storage in particular. I think there are still some things worth looking at. Noah On 11/15/2011 9:41 PM, Bjoern Hoehrmann wrote: * Tab Atkins Jr. wrote: On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adamsgl...@skynav.com wrote: Perhaps. But widely implemented does not necessarily imply widely used. In any case, support for or use of a feature of a WD or CR does not imply it must be present in REC. Use of a feature does, in fact, imply that, unless there are *very* good reasons why not. Specs and implementations advance together, and both constrain the other. Well, they advance from Working Draft to Working Draft and then it's too late to make changes before there is a Call for Implementations as the implementations have already been shipping for years. The Last Call is meant to avoid that, providing an opportunity to build a consensus even with people and organizations that cannot follow the day-to-day working group and implementation progress to prioritize their reviews. Which the Last Calls relevant to this thread obviously do not provide.
