Re: IndexedDB - renaming
On Jun 10, 2010, at 19:33 , Andrei Popescu wrote: Also, seems that the date of the spec is auto-generated so it's always the current date :) Yes, it is. I have a fix to use document.lastModified instead, I should probably patch it in. -- Robin Berjon - http://berjon.com/
Re: IndexedDB - renaming
On Thu, Jun 10, 2010 at 6:29 PM, Jonas Sicking jo...@sicking.cc wrote: Arg, drats, I missed the planning part of your email :) Sounds good to me, the only thing I would add is that I think we should remove the base-interfaces, like IDBObjectStore, and copy the relevant properties to both (async and sync) sub-interfaces. Agreed. (IIRC, this was mentioned in another thread earlier as well, and no one disagreed then either.) / Jonas On Thu, Jun 10, 2010 at 10:27 AM, Jonas Sicking jo...@sicking.cc wrote: I still see the old Request post-fixed names when looking at http://dev.w3.org/2006/webapi/IndexedDB/#async-api Despite the top of the file saying that this is the June 10th version. Is there somewhere else I should look? / Jonas On Thu, Jun 10, 2010 at 9:38 AM, Andrei Popescu andr...@google.com wrote: Hello, A while ago, we discussed some simple renaming of the IndexedDB interfaces. I have already closed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9789 as it was a very simple fix. I would like to recap the rest of the changes I am planning to make, just to make sure that everyone is ok with them: 1. Drop the Request prefix from our async interface names and add the Sync suffix to the sync interfaces. http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 2. Rename IDBIndexedDatabase to IDBFactory. My original proposal was also renaming IDBDatabase to IDBConnection but Jonas had an objection to that. So let's keep it IDBDatabase for now. Agreed. Closed it as WontFix. http://www.w3.org/Bugs/Public/show_bug.cgi?id=9791 What do you think? Thanks, Andrei
RE: Updates to File API
On Wednesday, June 02, 2010 5:27 PM, Arun Ranganathan wrote: On 6/2/10 5:06 PM, Jian Li wrote: Indeed, the URL scheme seems to be more sort of implementation details. Different browser vendors can choose the appropriate scheme, like Mozilla ships with moz-filedata. How do you think? Actually, I'm against leaving it totally up to implementations. Sure, the spec. could simply state how the URL behaves without mentioning format much, but we identified in the past [1] that it was wise to specify things reliably, so that developers didn't rely on arbitrary behavior in one implementation and expect something similar in another. It's precisely that genre of underspecified behavior that got us in trouble before ;-) -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html Do you think the URL scheme should be specified for each use of Blob or more broadly? For example, Blob is used in the File Reader API but also possibly in the Capture API in a different way. It might be useful to be able to use a different scheme for these different purposes to help the user agent route requests to the appropriate handler. Adrian.
RE: Updates to File API
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? Cheers, Adrian
Re: Updates to File API
One benefit of using the encoded origin is to do the security origin check in place, instead of resorting to a centralized authority, esp. under multi-process architecture. Considering getting and checking the origin before hitting the cache for the blob.url item. On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.comwrote: On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? Cheers, Adrian
Re: Updates to File API
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? The one advantage I can see is that putting the scheme into the URL allows the *implementation* to deduce the origin by simply looking at the URL-scheme. This avoids having to do a (potentially cross-process) lookup to get the origin. This could be useful for APIs which have to synchronously determine the origin of a given URL in order to throw an exception on an attempted cross-origin access. For example an XMLHttpRequest Level 1 implementation needs to synchronously determine if it should make a call to .open(...) throw or not based on the origin of the passed in URL. However I'm not sure if this is a problem in practice or not. It's entierly possible that the web platform is littered with situations where you need to do synchronous communication with whichever thread the networking code runs on. Firefox is still in the process of going multi-process, so I'll defer to other browsers with more experience in this area. / Jonas
Re: Updates to File API
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? The one advantage I can see is that putting the scheme into the URL allows the *implementation* to deduce the origin by simply looking at the URL-scheme. This avoids having to do a (potentially cross-process) lookup to get the origin. This could be useful for APIs which have to synchronously determine the origin of a given URL in order to throw an exception on an attempted cross-origin access. For example an XMLHttpRequest Level 1 implementation needs to synchronously determine if it should make a call to .open(...) throw or not based on the origin of the passed in URL. However I'm not sure if this is a problem in practice or not. It's entierly possible that the web platform is littered with situations where you need to do synchronous communication with whichever thread the networking code runs on. Firefox is still in the process of going multi-process, so I'll defer to other browsers with more experience in this area. Oh, and I should add that the implementation will of course still have to check once a url is loaded that the origin in the url matches the origin in whatever map is used to map urls to resources. I.e. if the implementation has handed out a url like: filedata:sheep.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752 and script changes that to: filedata:wolf.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752 then attempting to load the latter url should result in a 404 or similar. / Jonas
Re: Updates to File API
Another advantage is that... blobdata:// http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752 ... makes it clear to the end user who the responsible party is when these urls are visible in the user interface. (location bar, tooltips, etc). On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com wrote: On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things? The one advantage I can see is that putting the scheme into the URL allows the *implementation* to deduce the origin by simply looking at the URL-scheme. This avoids having to do a (potentially cross-process) lookup to get the origin. This could be useful for APIs which have to synchronously determine the origin of a given URL in order to throw an exception on an attempted cross-origin access. For example an XMLHttpRequest Level 1 implementation needs to synchronously determine if it should make a call to .open(...) throw or not based on the origin of the passed in URL. However I'm not sure if this is a problem in practice or not. It's entierly possible that the web platform is littered with situations where you need to do synchronous communication with whichever thread the networking code runs on. Firefox is still in the process of going multi-process, so I'll defer to other browsers with more experience in this area. / Jonas
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Friday, June 11, 2010 3:20 AM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com wrote: From: Kris Zyp [mailto:k...@sitepen.com] Sent: Thursday, June 10, 2010 4:38 PM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I had the same concerns Pablo did, but I don't feel strongly either way. Before we close on this, let me validate one more thing independently of the JS version. Are we going to have trouble when trying to expose these interfaces in C++? Not sure about other compilers and IDL processing tools, but I'm playing around with Visual Studio 2010 and while the COM IDL compiler will take delete as an interface member, my C++ compiler really doesn't like it. As far as I know there is no standard syntax to indicate that a symbol wasn't meant to be a keyword in C++, so having delete (or other C++ keywords for that matter) would be problematic. Am I missing something? -pablo
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro pablo.cas...@microsoft.comwrote: From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Friday, June 11, 2010 3:20 AM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com wrote: From: Kris Zyp [mailto:k...@sitepen.com] Sent: Thursday, June 10, 2010 4:38 PM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I had the same concerns Pablo did, but I don't feel strongly either way. Before we close on this, let me validate one more thing independently of the JS version. Are we going to have trouble when trying to expose these interfaces in C++? Not sure about other compilers and IDL processing tools, but I'm playing around with Visual Studio 2010 and while the COM IDL compiler will take delete as an interface member, my C++ compiler really doesn't like it. As far as I know there is no standard syntax to indicate that a symbol wasn't meant to be a keyword in C++, so having delete (or other C++ keywords for that matter) would be problematic. Am I missing something? Good point. Does anyone have a strong opinion on how much we should care about reserved word conflicts in language other than JavaScript? it seems like a slippery slope. As an example, IDBDatabase.description is actually used by the ObjectiveC base object class and so this caused some problems initially. We worked around it by having the ObjectiveC bindings generator add a suffix whenever an attribute named description is hit. (Something similar was done for hash and id in other APIs.) To be honest, I hadn't even considered bringing this up and asking for it to be changed, but if we're going to avoid delete because it's a reserved word in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps we should consider changing description as well? J
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Thu, Jun 10, 2010 at 5:54 PM, Pablo Castro pablo.cas...@microsoft.com wrote: From: Kris Zyp [mailto:k...@sitepen.com] Sent: Thursday, June 10, 2010 4:38 PM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On 6/10/2010 4:15 PM, Pablo Castro wrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Kris Zyp Sent: Thursday, June 10, 2010 9:49 AM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 I see that in the trunk version of the spec [1] that delete() was changed to remove(). I thought we had established that there is no reason to make this change. Is anyone seriously expecting to have an implementation prior to or without ES5's contextually unreserved keywords? I would greatly prefer delete(), as it is much more consistent with standard DB and REST terminology. My concern is that it seems like taking an unnecessary risk. I understand the familiarity aspect (and I like delete() better as well), but to me that's not a strong enough reason to use it and potentially cause trouble in some browser. So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I just checked with our JS team and we'll implement enough of ES5 in Firefox 4 that this won't be a problem for us. / Jonas
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Fri, Jun 11, 2010 at 2:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro pablo.cas...@microsoft.com wrote: From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Friday, June 11, 2010 3:20 AM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com wrote: From: Kris Zyp [mailto:k...@sitepen.com] Sent: Thursday, June 10, 2010 4:38 PM Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I had the same concerns Pablo did, but I don't feel strongly either way. Before we close on this, let me validate one more thing independently of the JS version. Are we going to have trouble when trying to expose these interfaces in C++? Not sure about other compilers and IDL processing tools, but I'm playing around with Visual Studio 2010 and while the COM IDL compiler will take delete as an interface member, my C++ compiler really doesn't like it. As far as I know there is no standard syntax to indicate that a symbol wasn't meant to be a keyword in C++, so having delete (or other C++ keywords for that matter) would be problematic. Am I missing something? Good point. Does anyone have a strong opinion on how much we should care about reserved word conflicts in language other than JavaScript? it seems like a slippery slope. As an example, IDBDatabase.description is actually used by the ObjectiveC base object class and so this caused some problems initially. We worked around it by having the ObjectiveC bindings generator add a suffix whenever an attribute named description is hit. (Something similar was done for hash and id in other APIs.) To be honest, I hadn't even considered bringing this up and asking for it to be changed, but if we're going to avoid delete because it's a reserved word in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps we should consider changing description as well? We've had to do this a few times in the past already. One example was Window.postMessage where we couldn't use the name PostMessage in C++ because it was a predefined macro on some platform (windows iirc, not to point fingers ;) ). We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. / Jonas
