- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 10 Feb 2011 18:26:02 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-webapps@w3.org
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow <jorlow@chromium.org> >> wrote: >> > What's the current thinking in terms of events that we're firing? I >> > remember we talked about this a bit, but I don't remember the conclusion >> > and >> > I can't find it captured anywhere. >> > Here's a brain dump of the requirements as I remember them: >> > * Everything should have a source attribute. >> > * Everything done in the context of a transaction should have a >> > transaction >> > attribute. (Probably even errors, which I believe is not the current >> > case.) >> > * Only success events should have a result. >> > * Only error events should have a code and a message....or should they >> > just >> > have an error attribute which holds an IDBDatabaseError object? (If >> > it's >> > the former, then do we even need an interface for IDBDatabaseError to be >> > defined?) >> > * IIRC, Jonas suggested at some point that maybe there should be >> > additional >> > attributes beyond just the source and/or objects should link to their >> > parents. (The latter probably makes the most sense, right? If so, I'll >> > bug >> > it.) >> > Is there anything I'm missing? >> > As far as I can tell, this means we need 5 events: an IDBEvent (with >> > source) >> > and then error with transaction, error without, success with, and >> > success >> > without. That seems kind of ugly though. >> > Another possibility is that we could put a transaction attribute on >> > IDBEvent >> > that's null when there's no transaction. And then error and success >> > would >> > have their own subclasses. To me, this sounds best. >> > Thoughts? >> >> Actually, I was proposing something entirely different. >> >> IDBRequest should look like this: >> >> interface IDBRequest : EventTarget { > > For each, what do we do when it's not available? Throw exception? Return > undefined? Null? Particularly in the errorCode case, it's not clear to me > what the right thing to do is. So there are two situations when the result is "not available". * After success/error has fired, but the "other" property is accessed. * Before either success or result has fired. I think generally avoiding throwing exceptions is a good thing. So for .errorCode I would say returning unidentified or 0 is the way to go. The latter is possibly more consistent with how other DOM APIs behave since they tend to return a specific type. The former might be more javascripty. I don't think it matters much as long as people can do if (!req.errorCode) { ...assume success... } In the latter case it might be consistent with the rest of indexedDB to throw NOT_ALLOWED_ERR. But going with "don't throw errors", it might be better to returning 0/undefined. But it does seem like a pretty bad bug if you do access these properties before having a result. So maybe exception is in fact better here. / Jonas >> >> attribute any result; >> attribute unsigned long errorCode; >> attribute DOMObject source; >> attribute IDBTransaction transaction; >> >> const unsigned short LOADING = 1; >> const unsigned short DONE = 2; >> readonly attribute unsigned short readyState; >> >> attribute Function onsuccess; >> attribute Function onerror; >> };
Received on Friday, 11 February 2011 02:27:05 UTC