Re: [IndexedDB] Constants and interfaces
On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in I think I'd only support this if it was just a stop-gap measure until WebIDL could add proper support. Is there any way to bring this up with those folks and get their feelings on the subject so whatever we do is consistent with the future directions of that spec? javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? It's possible, sure, but is anything like
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 31, 2010 at 4:41 AM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Aug 28, 2010 at 11:26 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in I think I'd only support this if it was just a stop-gap measure until WebIDL could add proper support. Is there any way to bring this up with those folks and get their feelings on the subject so whatever we do is consistent with the future directions of that spec? I can't say that I care much. Adding it to WebIDL seems fine, though I also could see the argument that if no other classes than IDBKeyRange needs multiple constructors, then there isn't much value to adding it to WebIDL. But I'm all for proposing it for inclusion in WebIDL. javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other
Re: [IndexedDB] Constants and interfaces
On 8/31/2010 12:03 PM, Jonas Sicking wrote: So IMHO we should heavily optimize for javascript, while ensuring that other languages are possible. Yes, please. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Constants and interfaces
On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? It's possible, sure, but is anything like this done on any other API? If not, I'd rather not reinvent the wheel here. To me, adding factory methods to IDBFactory seems more natural. I don't see any real disadvantages to accessing methods off of |indexedDB| rather than |IDBKeyRange|. I especially don't like the idea of some languages putting methods on the IDBFactory interface and some implementing them as static methods on IDBKeyRange, which might be unavoidable with what you're proposing? It'd be nice to hear what others think about this, btw. J
Re: [IndexedDB] Constants and interfaces
On Aug 24, 2010, at 10:30 AM, Jeremy Orlow wrote: 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? Andrei made changes in http://dvcs.w3.org/hg/IndexedDB/rev/378e74fd2c7a for http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790. I left a comment for him on 06-26: Because all the abstract interfaces were removed, it was necessary to correct NoInterfaceObject modifiers on IDBObjectStore, IDBCursor, IDBObjectStoreSync, and IDBCursorSync Nikunj
Re: [IndexedDB] Constants and interfaces
On Sat, Aug 28, 2010 at 5:31 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 27, 2010 at 7:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? It's possible, sure, but is anything like this done on any other API? If not, I'd rather not reinvent the wheel here. To me, adding factory methods to IDBFactory seems more natural. I don't see any real disadvantages to accessing methods off of |indexedDB| rather than |IDBKeyRange|. I especially don't like the idea of some languages putting methods on the IDBFactory interface and some implementing them as static methods on IDBKeyRange, which might be unavoidable with what you're proposing? It'd
Re: [IndexedDB] Constants and interfaces
On Fri, Aug 27, 2010 at 2:12 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 26, 2010 at 8:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. This isn't just an issue of implementation trickery. What's specced doesn't work. Leaving it as is is not an option. Agreed. We either need to figure out the right language to describe what we intended or we need to change it. As I mentioned, I tried to figure out what was needed spec wise, but couldn't. As far as I can tell, there isn't anything else out there trying to do this either, so it's very possible this behavior would require a change to the WebIDL spec. (And blocking on that is probably not a good idea given that it's been stagnant for so long and has quite a backlog of required changes at this point.) Can you (or anyone else) think of a way to spec it? I think the way to do it is as follows: * Remove the factory methods from the IDBKeyRange interface. The factory methods shouldn't be showing up on individual instances anyway. * Add prose below the interface description that states that in javascript, the interface object IDBKeyRange has the following methods: IDBKeyRange only (in any value); IDBKeyRange leftBound (in any bound, in optional boolean open); IDBKeyRange rightBound (in any bound, in optional boolean open); IDBKeyRange bound (in any left, in any right, in optional boolean openLeft, in optional boolean openRight); In other languages the same factory methods are exposed as static methods in a way that is appropriate for that language. If the language doesn't support static methods, the methods are exposed on the IDBFactory interface. * Make a special note that in javascript, the factory methods are *not* exposed on the IDBFactory interface. Does that sound workable? / Jonas
Re: [IndexedDB] Constants and interfaces
On Wed, Aug 25, 2010 at 6:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). Indeed, the factory methods on IDBKeyRange use a different syntax from every other method in the DOM. This was why we originally proposed a different syntax in our proposal. However I've come to like the current specced syntax quite a bit and would prefer to stick to it actually. It makes for a lot nicer javascript. We might want to change left/right bound to lower/upper bound, but other than that I'd prefer to stick to the current syntax. It does take some trickery to implement in gecko, but not enough to toss it out IMHO. / Jonas
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). But is there any way to override this behavior or can anyone point to other examples where this is done? Of course another option is to move the factory methods to IDBFactory (as was suggested earlier). This would just work since window.indexedDB() returns an IDBFactory object. If no one has any bright ideas about how to otherwise spec what's there, I'd suggest we make that change. I tried to figure all of this out on my own by reading the WebIDL spec, but I've found it almost impossible to digest. :-( 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. Done. 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. Ok, I guess we'll leave it then. J
[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] Constants and interfaces
On Tue, Aug 24, 2010 at 6:30 PM, Jeremy Orlow jor...@chromium.org 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
Re: [IndexedDB] Constants and interfaces
On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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 7:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow jor...@chromium.org 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:58 AM, Andrei Popescu andr...@google.com wrote: On Tue, Aug 24, 2010 at 6:30 PM, Jeremy Orlow jor...@chromium.org 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
