W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Event on commits (WAS: Proposal for async API changes)

From: Mikeal Rogers <mikeal.rogers@gmail.com>
Date: Thu, 10 Jun 2010 12:00:11 -0700
Message-ID: <AANLkTik6Hc6HXW5YBFiZQbjURhP3p77oGLHIvMfyQhgx@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Andrei Popescu <andreip@google.com>, Webapps WG <public-webapps@w3.org>
Ah, good point. I hadn't thought about just using postMessage in my
ontransactioncommitted, that'll work. Thanks.

-Mikeal

On Thu, Jun 10, 2010 at 11:48 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Jun 10, 2010 at 6:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Jun 10, 2010 at 6:31 AM, Andrei Popescu <andreip@google.com>
>> wrote:
>> > On Thu, Jun 10, 2010 at 1:39 PM, Jeremy Orlow <jorlow@chromium.org>
>> > wrote:
>> >> Splitting into its own thread since this isn't really connected to the
>> >> new
>> >> Async interface and that thread is already pretty big.
>> >>
>> >> On Wed, Jun 9, 2010 at 10:36 PM, Mikeal Rogers
>> >> <mikeal.rogers@gmail.com>
>> >> wrote:
>> >>>
>> >>> I've been looking through the current spec and all the proposed
>> >>> changes.
>> >>>
>> >>> Great work. I'm going to be building a CouchDB compatible API on top
>> >>> of IndexedDB that can support peer-to-peer replication without other
>> >>> CouchDB instances.
>> >>>
>> >>> One of the things that will entail is a by-sequence index for all the
>> >>> changes in a give "database" (in my case a database will be scoped to
>> >>> more than one ObjectStore). In order to accomplish this I'll need to
>> >>> keep the last known sequence around so that each new write can create
>> >>> a new entry in the by-sequence index. The problem is that if another
>> >>> tab/window writes to the database it'll increment that sequence and I
>> >>> won't be notified so I would have to start every transaction with a
>> >>> check on the sequence index for the last sequence which seems like a
>> >>> lot of extra cursor calls.
>> >>
>> >> It would be a lot of extra calls, but I'm a bit hesitant to add much
>> >> more
>> >> API surface area to v1, and the fall back plan doesn't seem too
>> >> unreasonable.
>> >>
>> >>>
>> >>> What I really need is an event listener on an ObjectStore that fires
>> >>> after a transaction is committed to the store but before the next
>> >>> transaction is run that gives me information about the commits to the
>> >>> ObjectStore.
>> >>>
>> >>> Thoughts?
>> >>
>> >> To do this, we could specify an
>> >> IndexedDatabaseRequest.ontransactioncommitted event that would
>> >> be guaranteed to fire after every commit and before we started the next
>> >> transaction.  I think that'd meet your needs and not add too much
>> >> additional
>> >> surface area...  What do others think?
>> >
>> > It sounds reasonable but, to clarify, it seems to me that
>> > 'ontransactioncommitted' can only be guaranteed to fire after every
>> > commit and before the next transaction starts in the current window.
>> > Other transactions may have already started in other windows.
>>
>> We could technically enforce that other transactions won't be allowed
>> to start until the event has fired in all windows that has the
>> database open.
>
> Sure, but I can't think of any reason you'd want such semantics.  Can you?
>>
>> Either way though, I'm wondering how this relates to the fact that you
>> can (in our proposal, I'm unclear what the current draft allows) have
>> several writing transactions at the same time, as long as they operate
>> on different tables. Here another transaction might have already
>> started by the time another transaction is committed. Be that in this
>> window or another.
>
> That's only true of dynamic transactions.  Mikeal, were you planning on
> using static or dynamic transactions?  If it's the latter, then I think
> Jonas has a good point and that this API might not help you after all.
> That said, I can think of other uses for notifications other windows have
> committed a transaction.  But I think many if not all of them can be
> emulated with postMessage...
> I guess I'm starting to lean towards thinking this is extra API surface area
> for limited gain.
> J
Received on Thursday, 10 June 2010 19:00:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT