On Thu, Jun 10, 2010 at 6:15 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Thu, Jun 10, 2010 at 6:31 AM, Andrei Popescu <andr...@google.com> > wrote: > > On Thu, Jun 10, 2010 at 1:39 PM, Jeremy Orlow <jor...@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.rog...@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