Re: IndexedDB TPAC agenda

Not sure if this is covered by "index keys", but you may consider adding:

 - Full-text indexing

To the agenda.

N


On Tue, Nov 2, 2010 at 11:15 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> I suspect internationalization is another thing where we can quickly
> make progress so lets try to get to that one too.
>
> / Jonas
>
> On Tue, Nov 2, 2010 at 11:58 AM, Jeremy Orlow <jorlow@chromium.org> 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 <
> Pablo.Castro@microsoft.com>
> > 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: public-webapps-request@w3.org [mailto:
> public-webapps-request@w3.org]
> >> On Behalf Of Pablo Castro
> >> Sent: Monday, November 01, 2010 10:39 PM
> >> To: Jeremy Orlow; Jonas Sicking
> >> Cc: public-webapps@w3.org
> >> 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: public-webapps-request@w3.org [mailto:
> public-webapps-request@w3.org]
> >> On Behalf Of Jeremy Orlow
> >> Sent: Monday, November 01, 2010 1:34 PM
> >> To: Jonas Sicking
> >> Cc: public-webapps@w3.org
> >> Subject: Re: IndexedDB TPAC agenda
> >>
> >> On Mon, Nov 1, 2010 at 12:23 PM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >> On Mon, Nov 1, 2010 at 5:13 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> >> > On Mon, Nov 1, 2010 at 11:53 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >> >>
> >> >> On Mon, Nov 1, 2010 at 4:40 AM, Jeremy Orlow <jorlow@chromium.org>
> >> >> wrote:
> >> >> > What items should we try to cover during the f2f?
> >> >> > On Mon, Nov 1, 2010 at 11:08 AM, Jonas Sicking <jonas@sicking.cc>
> >> >> > 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.
> >>
> >>
> >
> >
>
>