Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Whomever adds delete/continue back to the spec needs to inline into the spec an explanation of why it's ok per ES5. Most (all) of us grew up pre ES5 and *believe* that they're truly reserved keywords and that what you're doing is invalid. So without inlining the explanation into the spec, you're asking for people to think you're crazy. Personally, i think trying to mark something as locally unreserved is crazy, since you're fighting the web's collective knowledge. http://javascript.about.com/od/reference/g/rdelete.htm Definition: The delete statement deletes an object that was created using the new statement. Delete is a reserved word and cannot be used for anything other than deleting an object. Note that it seems clear that people here do not care about the web's collective knowledge, so I'm not asking you to stop.
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
There seems to be agreement that delete() is acceptable. Could you file a bug? / Jonas On Monday, July 5, 2010, Kris Zyp wrote: > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 6/15/2010 12:36 PM, Jonas Sicking wrote: >> On Mon, Jun 14, 2010 at 11:20 > PM, Pablo Castro >> wrote: > 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. >>> >>> I agree we can sort this out and certainly limitations on the >>> implementation language shouldn't surface here. The issue is > more >>> whether folks care about a C++ binding (or some other > language >>> with a similar issue) where we'll have to have a different > name >>> for this method. >>> >>> Even though I've been bringing this up I'm ok with keeping >>> delete(), I just want to make sure we understand all the >>> implications that come with that. >> >> I'm also ok with keeping delete(), as well as continue(). This >> despite realizing that it might mean that different C++ >> implementations might map these names differently into C++. >> >> / Jonas >> >> > > It sounds like returning to delete() for deleting records from a store > is agreeable. Can the spec be updated or are we still sticking with > remove()? > > - -- > Kris Zyp > SitePen > (503) 806-1841 > http://sitepen.com > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.9 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK > > 6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb > > =lG0c > > -END PGP SIGNATURE- > > > > >
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/2010 12:36 PM, Jonas Sicking wrote: > On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro > wrote: 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. >> >> I agree we can sort this out and certainly limitations on the >> implementation language shouldn't surface here. The issue is more >> whether folks care about a C++ binding (or some other language >> with a similar issue) where we'll have to have a different name >> for this method. >> >> Even though I've been bringing this up I'm ok with keeping >> delete(), I just want to make sure we understand all the >> implications that come with that. > > I'm also ok with keeping delete(), as well as continue(). This > despite realizing that it might mean that different C++ > implementations might map these names differently into C++. > > / Jonas > > It sounds like returning to delete() for deleting records from a store is agreeable. Can the spec be updated or are we still sticking with remove()? - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK 6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb =lG0c -END PGP SIGNATURE-
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Hi, (brief background before jumping out of the blue: I'm working with Andrei and Jeremy with the IDB implementation..) I'd like to mention the IDBCursor::continue is also problematic, as afaict "continue" is a reserved keyword in JS? oh, "delete" seems to be reserved as well: https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Reserved_Words Not sure what to suggest though, perhaps "move()" ? We can't have "next()", since the cursor is opened with a direction.. thoughts? Thanks, Marcus On Tue, Jun 15, 2010 at 7:20 AM, Pablo Castro wrote: > > From: Jonas Sicking [mailto:jo...@sicking.cc] > Sent: Friday, June 11, 2010 3:20 PM > >>> >> >> 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. > > Besides the maneuvering we'll have to do on the C++ side of things to avoid > clashes with language keywords, the question is whether we expect plugins and > such to add support for IndexedDB in existing browsers that don't do ES5. For > example: > http://code.google.com/p/firebreath/wiki/FireBreathUsers > >>> >>> 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. > > I agree we can sort this out and certainly limitations on the implementation > language shouldn't surface here. The issue is more whether folks care about a > C++ binding (or some other language with a similar issue) where we'll have to > have a different name for this method. > > Even though I've been bringing this up I'm ok with keeping delete(), I just > want to make sure we understand all the implications that come with that.. > > -pablo > > >
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/2010 12:40 PM, Jeremy Orlow wrote: > On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking wrote: > > On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro > mailto:pablo.cas...@microsoft.com>> > wrote: > >>> 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. > > > > I agree we can sort this out and certainly limitations on the > implementation language shouldn't surface here. The issue is > more whether folks care about a C++ binding (or some other > language with a similar issue) where we'll have to have a > different name for this method. > > > > Even though I've been bringing this up I'm ok with keeping > delete(), I just want to make sure we understand all the > implications that come with that. > > I'm also ok with keeping delete(), as well as continue(). This > despite > realizing that it might mean that different C++ implementations > might > map these names differently into C++. > > > Isn't continue a _JS_ reserved word though? Not as a property on the primary expected target language, EcmaScript 5. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXy9YACgkQ9VpNnHc4zAwlAwCguToFcLXY5FgGyL/7acDr4LKR LF0Anj96a/A6ChOeXCMHzlTv8A1xnhZy =TKKA -END PGP SIGNATURE-
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking wrote: > On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro > wrote: > >>> 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. > > > > I agree we can sort this out and certainly limitations on the > implementation language shouldn't surface here. The issue is more whether > folks care about a C++ binding (or some other language with a similar issue) > where we'll have to have a different name for this method. > > > > Even though I've been bringing this up I'm ok with keeping delete(), I > just want to make sure we understand all the implications that come with > that. > > I'm also ok with keeping delete(), as well as continue(). This despite > realizing that it might mean that different C++ implementations might > map these names differently into C++. > Isn't continue a _JS_ reserved word though?
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro wrote: >>> 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. > > I agree we can sort this out and certainly limitations on the implementation > language shouldn't surface here. The issue is more whether folks care about a > C++ binding (or some other language with a similar issue) where we'll have to > have a different name for this method. > > Even though I've been bringing this up I'm ok with keeping delete(), I just > want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. / Jonas
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, June 11, 2010 3:20 PM >> >> >> 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. Besides the maneuvering we'll have to do on the C++ side of things to avoid clashes with language keywords, the question is whether we expect plugins and such to add support for IndexedDB in existing browsers that don't do ES5. For example: http://code.google.com/p/firebreath/wiki/FireBreathUsers >> >> 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. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. -pablo
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Fri, Jun 11, 2010 at 2:05 PM, Jeremy Orlow wrote: > On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro > 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 >> 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
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Thu, Jun 10, 2010 at 5:54 PM, Pablo Castro 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 9:52 PM, Pablo Castro 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 > 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
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 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 1:54 AM, Pablo Castro 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 had the same concerns Pablo did, but I don't feel strongly either way. J
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
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. -pablo
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwRd04ACgkQ9VpNnHc4zAwyegCfQlUO66XszuZeZtFVNrfBjV56 eRIAoLDjGDTdRzvIeLtfRHFnDhopFKGv =ZhrJ -END PGP SIGNATURE-
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
>> 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. -pablo
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/2/2010 12:48 PM, Kris Zyp wrote: > > > On 2/1/2010 8:17 PM, Pablo Castro wrote: >> [snip] > > > >>> the existence of currentTransaction in the same class). > > > >>> "beginTransaction" would capture semantics more accurately. > b. > >>> ObjectStoreSync.delete: delete is a Javascript keyword, can > we > >>> use "remove" instead? > >> I'd prefer to keep both of these as is. Since commit and abort > are > >> part of the transaction interface, using transaction() to denote > >> the transaction creator seems brief and appropriate. As far as > >> ObjectStoreSync.delete, most JS engines have or should be > >> contextually reserving "delete". I certainly prefer delete in > >> preserving the familiarity of REST terminology. > > > >> [PC] I understand the term familiarity aspect, but this seems to > be > >> something that would just cause trouble. From a quick check with > >> the browsers I had at hand, both IE8 and Safari 4 reject scripts > >> where you try to add a method called ?delete? to an object?s > >> prototype. Natively-implemented objects may be able to > work-around > >> this but I see no reason to push it. remove() is probably > equally > >> intuitive. Note that the method ?continue? on async cursors are > >> likely to have the same issue as continue is also a Javascript > >> keyword. > > > > You can't use member access syntax in IE8 and Safari 4 because > they only implement EcmaScript3. But obviously, these aren't the > target versions, the future versions would be the target of this > spec. ES5 specifically contextually unreserves keywords, so > obj.delete(id) is perfectly valid syntax for all target browser > versions. ES5 predates Indexed DB API, so it doesn't make any sense > to design around an outdated EcmaScript behavior (also it is still > perfectly possible to set/call the delete property in ES3, you do > so with object["delete"](id)). > 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. [1] http://dvcs.w3.org/hg/IndexedDB/raw-file/d697d377f9ac/Overview.html#object-store-sync - -- Thanks, Kris - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwRF2EACgkQ9VpNnHc4zAyFgwCeIhWGFQFXCrGdhCqSg43YLEur mRcAn0hPK/EvQT17Oeg1EfT2VHp9goNF =UO8O -END PGP SIGNATURE-
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 19, 2010, at 3:39 PM, Maciej Stachowiak wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow > wrote: Nikunj would like to move the Indexed Database API spec to Last Call Working Draft (LCWD): http://dev.w3.org/2006/webapi/WebSimpleDB/ If you have any comments, please send them to public-webapps@w3.org by February 2. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Regards, Art Barstow We (Google) support this LC publication. We would, however, like time to gather meaningful experience with the spec before the last call review period ends. We expect we'll have this experience by the end of May. Would it be permissible to have a 4 month LC review period to facilitate this? We at Apple are also in reviewing the spec and would also like additional time to review. How is the review coming along? It would be useful to get incremental feedback and comments rather than a large set all at once. Does Apple have an ETA for completing the review? It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. It would really help if we can all check whether IndexedDB satisfies relevant technical requirements. Besides inverted indexes, I have ruled out any other feature requests that seem to expand the scope of this spec without commensurate benefits. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Hi All, On Jan 19, 2010, at 7:50 AM, Barstow Art (Nokia-CIC/Boston) wrote: Nikunj would like to move the Indexed Database API spec to Last Call Working Draft (LCWD): http://dev.w3.org/2006/webapi/WebSimpleDB/ If you have any comments, please send them to public-webapps@w3.org by February 2. My 1-line summary of the comments submitted for this CfC is that there is a significant amount of interest in this spec but that it is not ready to be published as a LCWD. As with all of our specs, please continue the technical discussions on this mail list. -Art Barstow
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/1/2010 8:17 PM, Pablo Castro wrote: > [snip] >> the existence of currentTransaction in the same class). > >> "beginTransaction" would capture semantics more accurately. b. >> ObjectStoreSync.delete: delete is a Javascript keyword, can we >> use "remove" instead? > I'd prefer to keep both of these as is. Since commit and abort are > part of the transaction interface, using transaction() to denote > the transaction creator seems brief and appropriate. As far as > ObjectStoreSync.delete, most JS engines have or should be > contextually reserving "delete". I certainly prefer delete in > preserving the familiarity of REST terminology. > > [PC] I understand the term familiarity aspect, but this seems to be > something that would just cause trouble. From a quick check with > the browsers I had at hand, both IE8 and Safari 4 reject scripts > where you try to add a method called ?delete? to an object?s > prototype. Natively-implemented objects may be able to work-around > this but I see no reason to push it. remove() is probably equally > intuitive. Note that the method ?continue? on async cursors are > likely to have the same issue as continue is also a Javascript > keyword. > You can't use member access syntax in IE8 and Safari 4 because they only implement EcmaScript3. But obviously, these aren't the target versions, the future versions would be the target of this spec. ES5 specifically contextually unreserves keywords, so obj.delete(id) is perfectly valid syntax for all target browser versions. ES5 predates Indexed DB API, so it doesn't make any sense to design around an outdated EcmaScript behavior (also it is still perfectly possible to set/call the delete property in ES3, you do so with object["delete"](id)). - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktogZkACgkQ9VpNnHc4zAytzgCeIssVuHKnsYaQ7Nd9Dhm5LxVN K+EAn32wlsyD17GKDqIPonEKLqt6v9nm =jTAo -END PGP SIGNATURE-
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
A few comments inline marked with [PC]. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Nikunj Mehta Sent: Sunday, January 31, 2010 11:37 PM To: Kris Zyp Cc: Arthur Barstow; public-webapps Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 On Jan 27, 2010, at 1:46 PM, Kris Zyp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a "count" property that returns "the total number of objects that share the current key". There is still no way to determine how many objects are within a range. Was the intent to make "count" return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). I agree with the concept. I have doubts about implementation success. However, I will include this in the editor's draft. [PC] I agree with Nikunj, I suspect that a implementations will have to just compute the count, as it's unlikely that updating intermediate nodes in the tree for each update would be desired (to try to maintain extra information for fast range size computation). At that point it's almost the same as user code iterating over the range (modulo the Javascript interface overhead). I'm also not sure how often you'd use this, as it would only work on simple conditions (no composite expressions, no functions in expressions) that happen to have an index. * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. Thanks for the pointer. I will look in to this as even Pablo had related requirements. [1] http://wiki.commonjs.org/wiki/Promises and a comment on this: On 1/26/2010 1:47 PM, Pablo Castro wrote: > 11. API Names > > a. "transaction" is really non-intuitive (particularly given > the existence of currentTransaction in the same class). > "beginTransaction" would capture semantics more accurately. b. > ObjectStoreSync.delete: delete is a Javascript keyword, can we use > "remove" instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving "delete". I certainly prefer delete in preserving the familiarity of REST terminology. [PC] I understand the term familiarity aspect, but this seems to be something that would just cause trouble. From a quick check with the browsers I had at hand, both IE8 and Safari 4 reject scripts where you try to add a method called "delete" to an object's prototype. Natively-implemented objects may be able to work-around this but I see no reason to push it. remove() is probably equally intuitive. Note that the method "continue" on async cursors are likely to have the same issue as continue is also a Javascript keyword. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3 X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU =W6Jx -END PGP SIGNATURE- -pablo
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 27, 2010, at 1:46 PM, Kris Zyp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a "count" property that returns "the total number of objects that share the current key". There is still no way to determine how many objects are within a range. Was the intent to make "count" return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). I agree with the concept. I have doubts about implementation success. However, I will include this in the editor's draft. * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. Thanks for the pointer. I will look in to this as even Pablo had related requirements. [1] http://wiki.commonjs.org/wiki/Promises and a comment on this: On 1/26/2010 1:47 PM, Pablo Castro wrote: > 11. API Names > > a. "transaction" is really non-intuitive (particularly given > the existence of currentTransaction in the same class). > "beginTransaction" would capture semantics more accurately. b. > ObjectStoreSync.delete: delete is a Javascript keyword, can we use > "remove" instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving "delete". I certainly prefer delete in preserving the familiarity of REST terminology. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3 X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU =W6Jx -END PGP SIGNATURE-
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Wed, Jan 27, 2010 at 4:46 PM, Kris Zyp wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A few comments I've been meaning to suggest: > > * count on KeyRange - Previously I had asked if there would be a way > to get a count of the number of objects within a given key range. The > addition of the KeyRange interface seems to be a step towards that, > but the cursor generated with a KeyRange still only provides a "count" > property that returns "the total number of objects that share the > current key". There is still no way to determine how many objects are > within a range. Was the intent to make "count" return the number of > objects in a KeyRange and the wording is just not up to date? > Otherwise could we add such a count property (countForRange maybe, or > have a count and countForKey, I think Pablo suggested something like > that). > > * Use promises for async interfaces - In server side JavaScript, most > projects are moving towards using promises for asynchronous interfaces > instead of trying to define the specific callback parameters for each > interface. I believe the advantages of using promises over callbacks > are pretty well understood in terms of decoupling async semantics from > interface definitions, and improving encapsulation of concerns. For > the indexed database API this would mean that sync and async > interfaces could essentially look the same except sync would return > completed values and async would return promises. I realize that > defining a promise interface would have implications beyond the > indexed database API, as the goal of promises is to provide a > consistent interface for asynchronous interaction across components, > but perhaps this would be a good time for the W3C to define such an > API. It seems like the indexed database API would be a perfect > interface to leverage promises. If you are interested in proposal, > there is one from CommonJS here [1] (the get() and call() wouldn't > apply here). With this interface, a promise.then(callback, > errorHandler) function is the only function a promise would need to > provide. > > [1] http://wiki.commonjs.org/wiki/Promises > To piggyback on these suggestions, in prototyping a couchdb-backed store for Kris Zyp's perstore [1], which uses IndexedDB as the store API, I came across a major use case that can't be supported by the IndexedDB API as defined: couchdb's MVCC model requires an object's revision (ETag) for a DELETE. There are obviously plenty of other values (for instance, conditional HTTP header values) that could be critical -- or just very helpful -- to pass into a store's CRUD (get, put, and delete) methods. Initially we thought we could just extend the API by tacking on an *options*object to each of the CRUD method signatures but this feels hacky -- especially given that "put" has a third boolean "noOverwrite" argument defined. Would it be feasible to specify an options object for get, put and delete (which could house "noOverwrite"). Certainly the IndexedDB API cannot possibly conceive of every use case -- explicitly defining this kind of extension point would be helpful while keeping the method signatures sane. Speaking of noOverwrite, perhaps it is my unfamiliarity with WebIDL but the semantics are not entirely clear. AFAICT the overwrite characteristics of a "put" could be any of "MUST be an insert", "MUST be an update", or "insert OR update". I see that noOverwrite is defined as optional boolean which suggests it could be true, false or undefined, potentially supporting any of these three cases -- true: , false: , undefined: . However only the "true" case is explicitly defined as throwing on failure (MUST be an insert), implying the false|undefined case is insert OR update. This does not allow disambiguating the "MUST update" case (e.g. HTTP If-Match: *), which seems problematic, or at the very least like a missed opportunity. (Also, a bikeshed: noOverwrite seems unnecessarily convoluted -- overwrite: true | false | undefined is a bit more intuitive.) [1] http://github.com/kriszyp/perstore
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A few comments I've been meaning to suggest: * count on KeyRange - Previously I had asked if there would be a way to get a count of the number of objects within a given key range. The addition of the KeyRange interface seems to be a step towards that, but the cursor generated with a KeyRange still only provides a "count" property that returns "the total number of objects that share the current key". There is still no way to determine how many objects are within a range. Was the intent to make "count" return the number of objects in a KeyRange and the wording is just not up to date? Otherwise could we add such a count property (countForRange maybe, or have a count and countForKey, I think Pablo suggested something like that). * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises and a comment on this: On 1/26/2010 1:47 PM, Pablo Castro wrote: > 11. API Names > > a. "transaction" is really non-intuitive (particularly given > the existence of currentTransaction in the same class). > "beginTransaction" would capture semantics more accurately. b. > ObjectStoreSync.delete: delete is a Javascript keyword, can we use > "remove" instead? I'd prefer to keep both of these as is. Since commit and abort are part of the transaction interface, using transaction() to denote the transaction creator seems brief and appropriate. As far as ObjectStoreSync.delete, most JS engines have or should be contextually reserving "delete". I certainly prefer delete in preserving the familiarity of REST terminology. Thanks, - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3 X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU =W6Jx -END PGP SIGNATURE-
RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
At Microsoft, we don't believe the spec is quite ready for Last Call. Based on our prototyping work, we're preparing some additional feedback that we think is more substantive than would be appropriate for Last Call comments. I anticipate that we will be able to post this feedback to the working group next Monday (25th Jan). From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking Sent: Tuesday, January 19, 2010 9:48 PM To: Maciej Stachowiak Cc: Arthur Barstow; public-webapps; Jeremy Orlow Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2 For what it's worth we are in the same situation at mozilla On Jan 19, 2010 3:40 PM, "Maciej Stachowiak" mailto:m...@apple.com>> wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: > On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow... We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
For what it's worth we are in the same situation at mozilla On Jan 19, 2010 3:40 PM, "Maciej Stachowiak" wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: > On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow... We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 19, 2010, at 3:39 PM, Maciej Stachowiak wrote: On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow > wrote: Nikunj would like to move the Indexed Database API spec to Last Call Working Draft (LCWD): http://dev.w3.org/2006/webapi/WebSimpleDB/ If you have any comments, please send them to public-webapps@w3.org by February 2. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Regards, Art Barstow We (Google) support this LC publication. We would, however, like time to gather meaningful experience with the spec before the last call review period ends. We expect we'll have this experience by the end of May. Would it be permissible to have a 4 month LC review period to facilitate this? (For some reason, I didn't get Jeremy's email.) I am completely open to keeping a long enough LC period to allow everyone a chance to perform detailed review of the spec. We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. I leave it to the chair to decide the best way to schedule this. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote: > On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow wrote: > Nikunj would like to move the Indexed Database API spec to Last Call Working > Draft (LCWD): > > http://dev.w3.org/2006/webapi/WebSimpleDB/ > > If you have any comments, please send them to public-webapps@w3.org by > February 2. > > Note the Process Document states the following regarding the > significance/meaning of a LCWD: > > [[ > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > Purpose: A Working Group's Last Call announcement is a signal that: > > * the Working Group believes that it has satisfied its relevant technical > requirements (e.g., of the charter or requirements document) in the Working > Draft; > > * the Working Group believes that it has satisfied significant dependencies > with other groups; > > * other groups SHOULD review the document to confirm that these dependencies > have been satisfied. In general, a Last Call announcement is also a signal > that the Working Group is planning to advance the technical report to later > maturity levels. > ]] > > Additionally, a LCWD should be considered feature-complete with all issues > resolved. > > If there are other groups that should be asked for comments, please forward > this email to them or identify the group(s). > > -Regards, Art Barstow > > > We (Google) support this LC publication. > > We would, however, like time to gather meaningful experience with the spec > before the last call review period ends. We expect we'll have this > experience by the end of May. Would it be permissible to have a 4 month LC > review period to facilitate this? We at Apple are also in reviewing the spec and would also like additional time to review. It doesn't matter that much to us if the review time is before or during Last Call, but we definitely can't do a meaningful review by February 2, and therefore cannot really sign off by that date on whether the document has satisfied relevant technical requirements, is feature-complete, and has all issues resolved. (As far as I can tell the document is less than 4 months old as an Editor's Draft and is about 60 pages long, so I hope it is reasonable to ask for some reasonable amount of review time.) Regards, Maciej
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow wrote: > Nikunj would like to move the Indexed Database API spec to Last Call > Working Draft (LCWD): > > http://dev.w3.org/2006/webapi/WebSimpleDB/ > > If you have any comments, please send them to public-webapps@w3.org by > February 2. > > Note the Process Document states the following regarding the > significance/meaning of a LCWD: > > [[ > http://www.w3.org/2005/10/Process-20051014/tr.html#last-call > Purpose: A Working Group's Last Call announcement is a signal that: > > * the Working Group believes that it has satisfied its relevant technical > requirements (e.g., of the charter or requirements document) in the Working > Draft; > > * the Working Group believes that it has satisfied significant dependencies > with other groups; > > * other groups SHOULD review the document to confirm that these > dependencies have been satisfied. In general, a Last Call announcement is > also a signal that the Working Group is planning to advance the technical > report to later maturity levels. > ]] > > Additionally, a LCWD should be considered feature-complete with all issues > resolved. > > If there are other groups that should be asked for comments, please forward > this email to them or identify the group(s). > > -Regards, Art Barstow > > We (Google) support this LC publication. We would, however, like time to gather meaningful experience with the spec before the last call review period ends. We expect we'll have this experience by the end of May. Would it be permissible to have a 4 month LC review period to facilitate this? Thanks, Jeremy
