Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 10:58 AM, Andrei Popescu wrote: > On Tue, Aug 24, 2010 at 6:30 PM, Jeremy Orlow wrote: >> Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I >> believe we had decided that all the objects with constants would have an >> interface object hanging off of window so it's possible to simply say >> "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone tries >> something like the following JS: |IDBCursor.continue()|? Given that we're >> using an interface object, I'd assume we throw some sort of exception or >> something? I tried to figure out the answer in the WebIDL spec (I imagine >> it's somewhere around >> here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a >> lot to wade through. Any advice would be great. >> Also, the spec still has "[NoInterfaceObject]" for a lot of the interfaces. >> I believe Nikunj did this by accident and was supposed to revert, but I >> guess he didn't? I should file a bug to get these removed, right? >> Another question: Right now all the error constants are on >> IDBDatabaseException which is an exception rather than an interface. Is >> this allowed? And even if so, should we put them on IDBDatabaseError >> instead, given that it's the class people will be using more often (with the >> async interface)? Or maybe we should duplicate the constants in both >> places? It just feels weird to me that I keep reaching into >> IDBDatabaseException for these constants. > > I wonder if it would make sense to group all constants into a separate > interface, which would have an interface object. The rest of the > interfaces would all be defined with [NoInterfaceObject]. What do you > think? I would prefer to stick to how things are done elsewhere and put constants on relevant interfaces. We likely do *not* want [NoInterfaceObject] on almost all interfaces anyway. Interface objects are useful to allow pages to extend prototypes and adding functions, for example adding back something similar to db.objectStore which we're killing. The only thing in the async API that I can see which should have [NoInterfaceObject] is IDBEnvironment. / Jonas
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking wrote: > On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow > wrote: > > Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) > I > > believe we had decided that all the objects with constants would have an > > interface object hanging off of window so it's possible to simply say > > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone > tries > > something like the following JS: |IDBCursor.continue()|? Given that > we're > > using an interface object, I'd assume we throw some sort of exception or > > something? I tried to figure out the answer in the WebIDL spec (I > imagine > > it's somewhere around > > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but > it's a > > lot to wade through. Any advice would be great. > > I definitely think we should handle this the same way that all other > interfaces does it. I.e. the same way that > window.Node.appendChild(...) does it. In the Firefox implementation we > just fall back to using our generic code for all this stuff, so > nothing special goes on in the IndexedDB implementation. > > And yes, I think WebIDL should be the one defining what should happen. > If it doesn't already someone should file a bug :) > OK, I'll look at our implementation of Node.appendChild and try to reverse engineer it from that. Because, as I mentioned, I have no idea what part of WebIDL specifies the behavior. :-) > Also, the spec still has "[NoInterfaceObject]" for a lot of the > interfaces. > > I believe Nikunj did this by accident and was supposed to revert, but I > > guess he didn't? I should file a bug to get these removed, right? > > Please do. > > > Another question: Right now all the error constants are on > > IDBDatabaseException which is an exception rather than an interface. Is > > this allowed? And even if so, should we put them on IDBDatabaseError > > instead, given that it's the class people will be using more often (with > the > > async interface)? Or maybe we should duplicate the constants in both > > places? It just feels weird to me that I keep reaching into > > IDBDatabaseException for these constants. > > Exception stuff has always confused me, but I think this is how idl > elsewhere does it. > > / Jonas >
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow wrote: > Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I > believe we had decided that all the objects with constants would have an > interface object hanging off of window so it's possible to simply say > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone tries > something like the following JS: |IDBCursor.continue()|? Given that we're > using an interface object, I'd assume we throw some sort of exception or > something? I tried to figure out the answer in the WebIDL spec (I imagine > it's somewhere around > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a > lot to wade through. Any advice would be great. I definitely think we should handle this the same way that all other interfaces does it. I.e. the same way that window.Node.appendChild(...) does it. In the Firefox implementation we just fall back to using our generic code for all this stuff, so nothing special goes on in the IndexedDB implementation. And yes, I think WebIDL should be the one defining what should happen. If it doesn't already someone should file a bug :) > Also, the spec still has "[NoInterfaceObject]" for a lot of the interfaces. > I believe Nikunj did this by accident and was supposed to revert, but I > guess he didn't? I should file a bug to get these removed, right? Please do. > Another question: Right now all the error constants are on > IDBDatabaseException which is an exception rather than an interface. Is > this allowed? And even if so, should we put them on IDBDatabaseError > instead, given that it's the class people will be using more often (with the > async interface)? Or maybe we should duplicate the constants in both > places? It just feels weird to me that I keep reaching into > IDBDatabaseException for these constants. Exception stuff has always confused me, but I think this is how idl elsewhere does it. / Jonas
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 6:30 PM, Jeremy Orlow wrote: > Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I > believe we had decided that all the objects with constants would have an > interface object hanging off of window so it's possible to simply say > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone tries > something like the following JS: |IDBCursor.continue()|? Given that we're > using an interface object, I'd assume we throw some sort of exception or > something? I tried to figure out the answer in the WebIDL spec (I imagine > it's somewhere around > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a > lot to wade through. Any advice would be great. > Also, the spec still has "[NoInterfaceObject]" for a lot of the interfaces. > I believe Nikunj did this by accident and was supposed to revert, but I > guess he didn't? I should file a bug to get these removed, right? > Another question: Right now all the error constants are on > IDBDatabaseException which is an exception rather than an interface. Is > this allowed? And even if so, should we put them on IDBDatabaseError > instead, given that it's the class people will be using more often (with the > async interface)? Or maybe we should duplicate the constants in both > places? It just feels weird to me that I keep reaching into > IDBDatabaseException for these constants. I wonder if it would make sense to group all constants into a separate interface, which would have an interface object. The rest of the interfaces would all be defined with [NoInterfaceObject]. What do you think? Thanks, Andrei
[IndexedDB] Constants and interfaces
Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) I believe we had decided that all the objects with constants would have an interface object hanging off of window so it's possible to simply say "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone tries something like the following JS: |IDBCursor.continue()|? Given that we're using an interface object, I'd assume we throw some sort of exception or something? I tried to figure out the answer in the WebIDL spec (I imagine it's somewhere around here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but it's a lot to wade through. Any advice would be great. Also, the spec still has "[NoInterfaceObject]" for a lot of the interfaces. I believe Nikunj did this by accident and was supposed to revert, but I guess he didn't? I should file a bug to get these removed, right? Another question: Right now all the error constants are on IDBDatabaseException which is an exception rather than an interface. Is this allowed? And even if so, should we put them on IDBDatabaseError instead, given that it's the class people will be using more often (with the async interface)? Or maybe we should duplicate the constants in both places? It just feels weird to me that I keep reaching into IDBDatabaseException for these constants. Thanks, Jeremy
RE: [IndexedDB] Let's remove IDBDatabase.objectStore()
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jeremy Orlow
Sent: Tuesday, August 24, 2010 12:40 AM
>> On Tue, Aug 24, 2010 at 12:43 AM, ben turner wrote:
>> Hi folks,
>>
>> We originally included IDBDatabase.objectStore() as a convenience
>> function because we figured that everyone would hate typing
>> |myDatabase.transaction('myObjectStore').objectStore('myObjectStore')|.
>> Unfortunately I think we should remove it - too many developers have
>> used the function without realizing that the returned object was tied
>> to a particular transaction. Any objections?
>>
>> It does seem like it could be confusing and it doesn't seem to save all that
>> many characters. So I'm fine with it.
+1
Re: [IndexedDB] Let's remove IDBDatabase.objectStore()
On Tue, Aug 24, 2010 at 12:43 AM, ben turner wrote:
> Hi folks,
>
> We originally included IDBDatabase.objectStore() as a convenience
> function because we figured that everyone would hate typing
> |myDatabase.transaction('myObjectStore').objectStore('myObjectStore')|.
> Unfortunately I think we should remove it - too many developers have
> used the function without realizing that the returned object was tied
> to a particular transaction. Any objections?
>
Removing it sounds like a good idea.
Andrei
Re: [IndexedDB] Let's remove IDBDatabase.objectStore()
On Tue, Aug 24, 2010 at 12:43 AM, ben turner wrote:
> Hi folks,
>
> We originally included IDBDatabase.objectStore() as a convenience
> function because we figured that everyone would hate typing
> |myDatabase.transaction('myObjectStore').objectStore('myObjectStore')|.
> Unfortunately I think we should remove it - too many developers have
> used the function without realizing that the returned object was tied
> to a particular transaction. Any objections?
>
It does seem like it could be confusing and it doesn't seem to save all that
many characters. So I'm fine with it.
J
