I had a major power outage on Nov 2 and could not join the meeting after the break between IndexedDB and File API. Also, I didn't really keep up with the discussions on DataCache API at TPAC. My apologies for that.
Nikunj On Nov 4, 2010, at 7:38 AM, Jeremy Orlow wrote: > Just to close the loop on this: Jonas, Pablo, Andrei, and I talked about all > of these items yesterday for several hours. Our plan is to either post bugs > or emails to the list by next Wednesday regarding everything that was > discussed so that we can continue the discussions there. > > J > > On Tue, Nov 2, 2010 at 4:44 PM, Jeremy Orlow <[email protected]> wrote: > We're meeting tomorrow (Wednesday) at 12:30 at room #4 on the third floor to > continue IndexedDB discussions. The plan is to go grab lunch somewhere and > then come back to room #4 and discuss stuff. The main topics will be error > handling and arrays/compound-keys/etc. > > J > > > On Tue, Nov 2, 2010 at 2:07 PM, Nikunj Mehta <[email protected]> wrote: > 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. >> >> >> > > >
