Propose: can implementors provide an update on their implementation status/plans?
Nikunj On Nov 2, 2010, at 3:58 AM, Jeremy Orlow wrote: > Great list! > > I propose we start with the various keys issues (I think we can make a lot of > progress quickly and it's somewhat fresh on our minds), go to dynamic > transactions (mainly are we going to support them), and then go from there. > > J > > On Tue, Nov 2, 2010 at 10:48 AM, Pablo Castro <[email protected]> > wrote: > To hit the ground running on this, here is a consolidated list of issues > coming both from the thread below and various pending bugs/discussions we've > had. I picked an arbitrary order and grouping, feel free to tweak in any way. > > - keys (arrays as keys, compound keys, general keypath restrictions) > - index keys (arrays as keys, empty values, general keypath restrictions) > - internationalization (collation specification, collation algorithm) > - quotas (how do apps request more storage, is there a temp/permanent > distinction?) > - error handling (propagation, relationship to window.error, db scoped event > handlers, errors vs return empty values) > - blobs (be explicit about behavior of blobs in indexeddb objects) > - transactions error modes (abort-on-unwind in error conditions; what happens > when user leaves the page with pending transactions?) > - transactions isolation/concurrent aspects > - transactions scopes (dynamic support) > - synchronous api > > Thanks > -pablo > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Pablo Castro > Sent: Monday, November 01, 2010 10:39 PM > To: Jeremy Orlow; Jonas Sicking > Cc: [email protected] > Subject: RE: IndexedDB TPAC agenda > > A few other items to add to the list to discuss tomorrow: > > - Blobs support: have we discussed explicitly how things work when an object > has a blob (file, array, etc.) as one of its properties? > - Close on collation and international support > - How do applications request that they need more storage? And related to > this, at some point we discussed temporary vs permanent stores. Close on the > whole story of how space is managed. > - Database-wide exception handlers > > Looking forward to the discussion tomorrow. > > -pablo > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Jeremy Orlow > Sent: Monday, November 01, 2010 1:34 PM > To: Jonas Sicking > Cc: [email protected] > Subject: Re: IndexedDB TPAC agenda > > On Mon, Nov 1, 2010 at 12:23 PM, Jonas Sicking <[email protected]> wrote: > On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow <[email protected]> wrote: > > On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking <[email protected]> wrote: > >> > >> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow <[email protected]> wrote: > >> > What items should we try to cover during the f2f? > >> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking <[email protected]> wrote: > >> >> > >> >> > P.S. I'm happy to discuss all of this f2f tomorrow rather than over > >> >> > email > >> >> > now. > >> >> > >> >> Speaking of which, would be great to have an agenda. Some of the > >> >> bigger items are: > >> >> > >> >> * Dynamic transactions > >> >> * Arrays-as-keys > >> >> * Arrays and indexes (what to do if the keyPath for an index evaluates > >> >> to an array) > >> >> * Synchronous API > >> > > >> > * Compound keys. > >> > * What should be allowed in a keyPath. > >> > >> Aren't "compound keys" same as "arrays-as-keys"? > > > > Sorry, I meant to say compound indexes. > > We've talked about using indexes in many different ways--including compound > > indexes and allowing keys to include indexes. I assumed you meant the > > latter....? > I'm lost as to what you're saying here. Could you elaborate? Are you > saying "index" when you mean "array" anywhere? > > oops. Yes, I meant to say: "We've talked about using arrays in many > different ways--including compound indexes and allowing keys to include > arrays. I assumed you meant the latter....?" > > >> * What should happen if an index's keyPath points to a property which > >> doesn't exist or which isn't a valid key-value? (same general topic as > >> "arrays and indexes" above) > > > > We've talked about this several times. It'd be great to settle on something > > once and for all. > Agreed. > > >> * What happens if the user leaves a page in the middle of a > >> transaction? (this might be nice to tackle since there'll be lots of > >> relevant people in the room) > > > > I'm pretty sure this is simple: if there's an onsuccess/onerror handler that > > has not yet fired (or we're in the middle of firing), then you abort the > > transaction. If not, the behavior is undefined (because there's no way the > > app could have observed the difference anyway). The aborting behavior is > > necessary since the user could have planned to execute additional commands > > atomically in the handler. > There is also the option to let the transaction finish. They should be > short-lived so it shouldn't be too bad. > > I.e. keep the page alive for a bit longer in the background or something that > blocks page unload? Is there precedent for this elsewhere? This sounds > pretty complicated to get right both in terms of implementation and speccing. > Let's chat about it though. > > >> * Error handling > > > > What do you mean by this? > How to handle exceptions in various places. Where (error) events > propagate. How does it relate to window.onerror. What happens if you > do/don't call preventDefault on the error event? > > > Sounds good. > > >
