- From: Mikeal Rogers <mikeal.rogers@gmail.com>
- Date: Thu, 10 Jun 2010 12:00:11 -0700
- 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 UTC