- From: Nikunj Mehta <nikunj@o-micron.com>
- Date: Mon, 1 Feb 2010 00:02:44 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-webapps@w3c.org
Hi all, Sorry to be slow in responding to all the feedback on Indexed DB. As you know, this is now my unpaid work and I am trying my best to respond to comments before the weekend is up. But this is good. Please keep the feedback and early implementation experience coming. On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote: > I've started work on implementing the IndexedDB bindings in WebKit > as a way to sanity check the API. I figure it's easiest to trickle > feedback to this list rather than save it all up for a big thread, > but I'm happy to do that if it's preferred. I prefer to get incremental comments unless there is a major hole in the spec and you need time to digest it and prepare a comprehensive proposal > > Interfaces I've looked at so far: > IDBEnvironment > IndexedDatabaseRequest > IDBRequest > IDBDatabaseError > IDBDatabaseException > > > First of all, I just wanted to say that I found the event based > nature of IndexedDatabaseRequest/IDBRequest fairly cumbersome. Why > not just have open take in a onsuccess and onerror callbacks and > return an object which has the ready state, an abort method, and > maybe an error code? It seems as though the event based API is > actually more confusing and artificially limiting (only one open > request in flight at a time) than is necessary. Every approach has its pros and cons. More than with other APIs, a database API that is all three - low-level, easy to program, and asynchronous - is not easy to get. I don't know for sure that we can satisfy all three. I am going to take one more crack at this and have this item on my to-do list. > > I assume that the limitation is only one database _opening_ in > flight at once, and not a limitation that you can only have one > database open ever? Correct. Only one _in-flight_ request on an object. If we had a DataCache-style API, every synchronous call would return a result, and an asynchronous call would return a "promise". It would be more flexible, but no easier to deal with. > > What is IDBRequest.error when there is no error? null? When would > it be reset? The next time you call open? I have clarified this. Any time request is in INITIAL or LOADING state, error is null. It would be reset whenever the request transitions from DONE back to LOADING state. > > What happens when you call abort and there is no pending open? Is > it a no-op? No-op is the correct behavior. > > Is it really necessary to have a separate IDBDatabaseException and > IDBDatabaseError? I know one is technically an exception and one is > technically an interface, but it seems a bit silly. Also, it seems > as though they both share the same codes, but the codes are only > defined in IDBDatabaseException? If so, I'm not sure it's clear > enough in the spec. Do you have a Web IDL proposal for this? I would love to be correct and satisfy you. However, I am not an expert in the business of WebIDL. > > But really, does IndexedDB really need its own error and exception > classes? At very least, I know the WebSQLDB spec has a very similar > error class. And I suspect there are others, though I didn't > immediately find anything looking through the HTML5 spec. XHR defines codes, but no new exceptions. File API has both and a style similar to Indexed Database > Maybe these types of interfaces should be specified in parent specs > and not duplicated in those that depend on them? I am willing to go with whatever works for everyone. > > In 3.4.5 probably means to say "events" rather than "callbacks" in > the first sentence. Yes > > In 3.4.2, queue is mispelled as "aueue". Gotcha > > > That's all I have for now. I've skimmed over the whole spec but > only read carefully these sections, so please excuse me if any of my > questions can be answered from text elsewhere in the spec. (Though > maybe it would be a sign that the relevant sections should be more > clear?) > > Thanks! > J
Received on Monday, 1 February 2010 08:04:02 UTC