[Bug 9790] Request is not a good suffix for all the async interfaces in IndexedDB
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9790 Nikunj Mehta changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from Nikunj Mehta 2010-06-26 23:59:54 --- Because all the abstract interfaces were removed, it was necessary to correct NoInterfaceObject modifiers on IDBObjectStore, IDBCursor, IDBObjectStoreSync, and IDBCursorSync -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [IndexedDB] Atomic schema changes
On Sat, Jun 26, 2010 at 10:09 AM, Jonas Sicking wrote:
> On Fri, Jun 25, 2010 at 2:43 AM, Jeremy Orlow wrote:
> >> > I'm OK with making createObjectStore/createIndex synchronous. It
> would
> >> > definitely make such code cleaner and I don't see a major downside,
> but
> >> > at
> >> > the same time I feel like this API is starting to get kind of ad-hoc
> and
> >> > unintuitive to a new user. Having the create and the remove functions
> >> > completely different and in different places seems weird.
> >> > So I agree with either A or leaving things as originally proposed by
> >> > Jonas
> >> > in "[IndexDB] Proposal for async API changes".
> >>
> >> Well, there's no reason not to make the same changes to
> >> removeObjectStore/removeIndex. Though the more I think with this
> >> design createObjectStore and removeObjectStore can stay on IDBDatabase
> >> and simply throw if called outside the appropriate transaction
> >> callback.
> >>
> >> Here is the revised proposal:
> >>
> >> interface IDBDatabase {
> >>...
> >>IDBObjectStore createObjectStore (in DOMString name, in optional
> >> DOMString keyPath, in optional boolean autoIncrement);
> >>void removeObjectStore (in DOMString storeName);
> >>...
> >> };
> >>
> >> interface IDBObjectStore {
> >>...
> >>IDBIndex createIndex (in DOMString name, in DOMString keyPath, in
> >> optional boolean unique);
> >>IDBRequest removeIndex (in DOMString indexName);
> >>...
> >> };
> >>
> >> Where createObjecStore/createIndex throws if a objectStore or index of
> >> the given name already exists, if the keyPath has an invalid syntax,
> >> or if the function is called when not inside a version-change
> >> transaction callback. And removeObjectStore/removeIndex throws if the
> >> objectStore or index doesn't exist or if the function is called when
> >> not inside a version-change transaction callback.
> >>
> >> Throwing if not inside the right type of callback isn't a super clean
> >> solution, but is really not that different from how add/put throws if
> >> called when not inside a READ_WRITE transaction.
> >
> > Just to be clear, no async function (one that returns an IDBRequest)
> should
> > _ever_ throw. (They should only call onerror.) I assume you didn't mean
> > "add/put throws" literally?
>
> Well, there's no reason we couldn't make add/put throw if called from
> inside the wrong type of transaction. I guess I don't feel strongly
> about it, but it seems to me that calling put from inside a READ_ONLY
> transaction is a much bigger mistake than writing a duplicate key or
> running out of disc space. Additionally it's a situation where we
> synchronously know that there is a bug in the program.
>
When this came up before, the thought was that it'd be confusing to web
developers which errors would raise immediately and which would call the
error callback. My feeling is that consistency is more useful than raising
right away for errors like this. (Plus, if we find it hard to get web
developers to do any error checking, it seems even harder to get them to do
it in 2 ways. :-)
> >> > But, I feel pretty strongly that a setVersion/schema change
> transaction
> >> > should not simply kill off anything else currently running. The
> reason
> >> > is
> >> > that it's not hard for apps to recover from a connection failing, but
> it
> >> > is
> >> > hard to handle a transaction failing in an unpredictable way.
> >> > Especially
> >> > static transactions (which should rarely fail committing since
> >> > serialization
> >> > can be guaranteed before the transaction starts).
> >>
> >> That might be a good idea for v1. I was planning on doing a separate
> >> thread for setVersion, but maybe it's tied enough to the topic of
> >> schema changes that it makes sense to bring up here.
> >>
> >> What I suggest is that when setVersion is called, we fire
> >> 'versionchange' event on all other open IDBDatabase objects. This
> >> event contains information of what the desired new version number is.
> >> If no other IDBDatabase objects are open for the specific database, no
> >> 'versionchange' events are fired. This allows pages using the old
> >> schema version to automatically save any pending data (for example any
> >> draft emails) and display UI to the user suggesting that the tab be
> >> closed. If possible without dataloss, the tab could even reload itself
> >> to automatically load an updated version of the page which uses the
> >> new schema version.
> >>
> >> The 'versionchange' event would use an interface like
> >>
> >> interface IDBVersionEvent : IDBEvent {
> >> readonly attribute string version;
> >> };
> >
> > First of all, what I was originally advocating (sorry for not being
> clear)
> > is that we should kill the database connection but not until all active
> > transactions are complete. Though we should probably block new
> transactions
> > from starting once setVersion is called.
> > But I really like your versionchange event
Re: [IndexedDB] Computed indexes
On Sat, Jun 26, 2010 at 12:11 PM, Jonas Sicking wrote:
> On Thu, Jun 24, 2010 at 7:01 AM, Jeremy Orlow wrote:
> >> >> 4. Maciej expressed concern that this might make it impossible to
> >> >> expose IndexedDB to non-JS languages such as ObjectiveC
> >> >>
> >> >> Let me address these in order (for the purposes of this discussion
> >> >> I'll use a separate function to create one of these indexes called
> >> >> createExpressionIndex. I'd prefer to do the bike-shedding afterward
> if
> >> >> possible):
> >> >> While I think 1 is unfortunate, i don't think it's a big deal.
> >> >> Fortunately Javascript has the nice feature that it allows functions
> >> >> to be serialized into strings, which means that while you can't do
> >> >> myObjectStore.createExpressionIndex("myIndex", function(val) { return
> >> >>
> >> >> });
> >> >> you can do
> >> >> myObjectStore.createExpressionIndex("myIndex", (function(val) {
> return
> >> >> }).toString());
> >> >
> >> > Do most JS engines allow _any_ function to be stored away for later?
> >>
> >> If you mean if _any_ function can be serialized using toString(), then
> >> yes, I believe so. Though of course serializing loses all scope
> >> references so it's not guaranteed to work. And non-builtin functions.
> >> Functions like Array.sort or Document.getElementById can of course not
> >> be serialized.
> >
> > This may be true of JavaScript and even many other interpreted languages,
> > but it's not true of many (most?) compiled languages. How would we
> handle
> > this in the spec? Would we say it's unsupported in v1 or say that such
> > implementations would define their own language (or use an existing
> > interpreted language) as they see fit? I guess this isn't a deal breaker
> > since JavaScript really is the main target for this, but it's somewhat
> > unfortunate.
>
> Like I said in an earlier email in this thread, we can fairly easily
> solve this using WebIDL. All that we really need here is a callback
> which can be called after browser restarts. Javascript doesn't provide
> any such means, which is why we have to resort to passing in a string.
> However in for example Java I believe you could provide enough
> information that the IndexedDB implementation can find the proper
> class and function even after application restart.
>
How would you do that in C/C++ though? As far as I know, Java is one of the
few languages where this is actually true. And even then it seems a bit
clunky. In C/C++, passing in a function pointer would not work once you
re-compile the program.
> However what I really think is the important question here is if the
> people that expressed concern about tying to javascript in the past
> are concerned about the more specific technical proposals that have
> been made since then.
>
I'm not sure if people who could make such an objection are watching these
threads very carefully (if at all), so I think we'll need to be more
proactive if we really want to get their advice. (i.e. at the very least,
start a new, specific thread on this topic with an obvious subject.)
> >> > What is the difference between an "expressionIndex" and a keyPath? It
> >> > seems
> >> > like they're doing about the same thing. My proposal to allow keyPath
> >> > to be
> >> > artibrary JavaScript and then have the value being inserted be the
> >> > global
> >> > scope actually sounds almost identical to what you're doingexcept
> >> > more
> >> > in the relm of what JS engines already do (since it's much like an
> >> > eval).
> >>
> >> It is about the same thing yes. Though presumably an implementation
> >> could optimize "evaluating" the keyPath heavily. Much more so than a
> >> generic expression.
> >
> > Howso? Any implementation should be able to cache the compiled/JITed
> form
> > of the string passed into it's internal implementation of eval.
>
> Executing a complied expression, including firing up all the contexts
> needed to run a piece of javascript, is at least in the firefox js
> engine, significantly more expensive than simply grabbing the relevant
> value as you serialize the javascript object into the database.
>
> Additionally, for a simple keyPath you don't have to worry about
> cloning objects or implementing copy-on-write semantics.
>
> Finally, you can perform optimizations such as not updating indexes if
> you notice that the relevant property doesn't change during calls to
> objectStore.put() and cursor.update().
>
> All in all I think keyPaths are preferrable when they are possible.
> Full on expressions will likely always be slower and more cumbersome,
> but they seem better than the alternatives when the value isn't stored
> directly in the stored object.
>
Ahh! I think I see why we're both having so hard of a time understanding
each other. I've been talking about various proposals for what keyPath
would be and you're talking about a proposal that'd be in addition to some
"simple" keyPath proposal (that could easily ha
Re: Thoughts on WebNotification
On Sat, Jun 26, 2010 at 10:47 AM, Jonas Sicking wrote:
> On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow wrote:
> > On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner
> wrote:
> >>
> >> I have been thinking a bit on Desktop Notifications [1]. After
> reviewing
> >> the Web Notification specification [2], I would like to propose the
> >> following changes:
> >>
> >>
> >> 1) Factor out the permission api into a new interface and/or spec. The
> >> ability to test for a permission without bring up a UI would improve the
> UX
> >> of device access. I could imagine implementing this feature for use
> with
> >> Geolocation as well as notifications. For example:
> >>
> >> interface Permissions {
> >>
> >> // permission values
> >> const unsigned long PERMISSION_ALLOWED = 0;
> >> const unsigned long PERMISSION_UNKNOWN = 1;
> >> const unsigned long PERMISSION_DENIED = 2;
> >>
> >> void checkPermission(in DOMString type, in Function callback);
> >>
> >> }
> >>
> >> Then we could do something like:
> >>
> >> navigator.permissions.checkPermission("desktop-notification",
> >> function(value) {});
> >>
> >> or
> >>
> >> navigator.permissions.checkPermission("geolocation", function(value)
> {});
> >>
> >>
> >>
> >> 2) Add language to the spec to indicate that the DOMStrings used
> >> |createNotification| are not to include any mark up. Basically,
> >> implementations are going to hand off notifications to system-level
> >> services. For example, on the Mac, GROWL does not handle any mark up...
> >> their API just takes plain strings. I'd like to see the API reflect
> this
> >> reality. Something like "the |title| and |body| arguments are to be
> treated
> >> as plain text"... or some such language.
> >>
> >>
> >>
> >> 3) Move Web notifications to a version 2 of the specification. For the
> >> most basic use cases, this API isn't required and a web developer could
> use
> >> the more base API to simulate this. Furthermore, as I mentioned above,
> many
> >> system-level notification services know nothing about rendering html.
> >
> > I'm happy with this course of action, but first I wanted to ask why not
> the
> > "gracefully degrade" suggestion from the "Notifications" thread started
> on
> > the 3rd of Feb. As far as I can tell, it was never seriously considered,
> > but several of us brought it up. And I feel like it'd be a much better
> way
> > forward than having a different interface for html based notifications
> and
> > text notifications.
> > (The basic idea was to accept either text or html and then if it's the
> > latter and the notification scheme doesn't support it, we'd use some
> simple,
> > specced heuristics to extract data to be used. In the thread, there were
> > some specific ideas about how the transformations could work. But from a
> > quick skim, I couldn't find any reasons why it was a bad idea.)
>
> I think history has showed that "optional" features generally work
> pretty poorly. While there are decent heuristics available to extract
> textual data from html, I doubt that they'll be good enough. For
> example I suspect that people will send notifications like:
>
> "You've got mail. Click here to read it"
> ""
> "Would you like to take our survey? type=submit value=yes>"
>
Which proposal are you in favor of then? Your first paragraph seems to
agree with me and your second (which is fairly compelling) seems to
disagree.
J
Re: [IndexedDB] Computed indexes
On Thu, Jun 24, 2010 at 7:01 AM, Jeremy Orlow wrote:
>> >> 4. Maciej expressed concern that this might make it impossible to
>> >> expose IndexedDB to non-JS languages such as ObjectiveC
>> >>
>> >> Let me address these in order (for the purposes of this discussion
>> >> I'll use a separate function to create one of these indexes called
>> >> createExpressionIndex. I'd prefer to do the bike-shedding afterward if
>> >> possible):
>> >> While I think 1 is unfortunate, i don't think it's a big deal.
>> >> Fortunately Javascript has the nice feature that it allows functions
>> >> to be serialized into strings, which means that while you can't do
>> >> myObjectStore.createExpressionIndex("myIndex", function(val) { return
>> >>
>> >> });
>> >> you can do
>> >> myObjectStore.createExpressionIndex("myIndex", (function(val) { return
>> >> }).toString());
>> >
>> > Do most JS engines allow _any_ function to be stored away for later?
>>
>> If you mean if _any_ function can be serialized using toString(), then
>> yes, I believe so. Though of course serializing loses all scope
>> references so it's not guaranteed to work. And non-builtin functions.
>> Functions like Array.sort or Document.getElementById can of course not
>> be serialized.
>
> This may be true of JavaScript and even many other interpreted languages,
> but it's not true of many (most?) compiled languages. How would we handle
> this in the spec? Would we say it's unsupported in v1 or say that such
> implementations would define their own language (or use an existing
> interpreted language) as they see fit? I guess this isn't a deal breaker
> since JavaScript really is the main target for this, but it's somewhat
> unfortunate.
Like I said in an earlier email in this thread, we can fairly easily
solve this using WebIDL. All that we really need here is a callback
which can be called after browser restarts. Javascript doesn't provide
any such means, which is why we have to resort to passing in a string.
However in for example Java I believe you could provide enough
information that the IndexedDB implementation can find the proper
class and function even after application restart.
However what I really think is the important question here is if the
people that expressed concern about tying to javascript in the past
are concerned about the more specific technical proposals that have
been made since then.
>> > What is the difference between an "expressionIndex" and a keyPath? It
>> > seems
>> > like they're doing about the same thing. My proposal to allow keyPath
>> > to be
>> > artibrary JavaScript and then have the value being inserted be the
>> > global
>> > scope actually sounds almost identical to what you're doingexcept
>> > more
>> > in the relm of what JS engines already do (since it's much like an
>> > eval).
>>
>> It is about the same thing yes. Though presumably an implementation
>> could optimize "evaluating" the keyPath heavily. Much more so than a
>> generic expression.
>
> Howso? Any implementation should be able to cache the compiled/JITed form
> of the string passed into it's internal implementation of eval.
Executing a complied expression, including firing up all the contexts
needed to run a piece of javascript, is at least in the firefox js
engine, significantly more expensive than simply grabbing the relevant
value as you serialize the javascript object into the database.
Additionally, for a simple keyPath you don't have to worry about
cloning objects or implementing copy-on-write semantics.
Finally, you can perform optimizations such as not updating indexes if
you notice that the relevant property doesn't change during calls to
objectStore.put() and cursor.update().
All in all I think keyPaths are preferrable when they are possible.
Full on expressions will likely always be slower and more cumbersome,
but they seem better than the alternatives when the value isn't stored
directly in the stored object.
>> Allowing keyPath to be an arbitrary expression turns out to result in
>> weird edge cases once you define all details. Say that you're storing
>> the value:
>>
>> { foo: 5, bar: 10 }
>>
>> You want to evaluate the expression in a context where "foo" and "bar"
>> are in scope. But you also don't want to evaluate with the value as
>> the global object as then "a = 5" would modify the value as that sets
>> a global variable. I.e. something like "t = foo*foo; bar + t;" would
>> add a 't' property to value. And you also don't want to evaluate the
>> expression in a context where the value is the current scope as then
>> "var a = 5" would modify the value.
>>
>> Additionally, you have to define what value is returned. We could do
>> like 'eval' is doing and say that the last evaluated expression is
>> what is returned. However eval doesn't let you return early using the
>> 'return' statement which might be practical.
>>
>> These problems could possibly be overcome though. I'll have to check
>> with people that know JS
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow wrote:
> On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner wrote:
>>
>> I have been thinking a bit on Desktop Notifications [1]. After reviewing
>> the Web Notification specification [2], I would like to propose the
>> following changes:
>>
>>
>> 1) Factor out the permission api into a new interface and/or spec. The
>> ability to test for a permission without bring up a UI would improve the UX
>> of device access. I could imagine implementing this feature for use with
>> Geolocation as well as notifications. For example:
>>
>> interface Permissions {
>>
>> // permission values
>> const unsigned long PERMISSION_ALLOWED = 0;
>> const unsigned long PERMISSION_UNKNOWN = 1;
>> const unsigned long PERMISSION_DENIED = 2;
>>
>> void checkPermission(in DOMString type, in Function callback);
>>
>> }
>>
>> Then we could do something like:
>>
>> navigator.permissions.checkPermission("desktop-notification",
>> function(value) {});
>>
>> or
>>
>> navigator.permissions.checkPermission("geolocation", function(value) {});
>>
>>
>>
>> 2) Add language to the spec to indicate that the DOMStrings used
>> |createNotification| are not to include any mark up. Basically,
>> implementations are going to hand off notifications to system-level
>> services. For example, on the Mac, GROWL does not handle any mark up...
>> their API just takes plain strings. I'd like to see the API reflect this
>> reality. Something like "the |title| and |body| arguments are to be treated
>> as plain text"... or some such language.
>>
>>
>>
>> 3) Move Web notifications to a version 2 of the specification. For the
>> most basic use cases, this API isn't required and a web developer could use
>> the more base API to simulate this. Furthermore, as I mentioned above, many
>> system-level notification services know nothing about rendering html.
>
> I'm happy with this course of action, but first I wanted to ask why not the
> "gracefully degrade" suggestion from the "Notifications" thread started on
> the 3rd of Feb. As far as I can tell, it was never seriously considered,
> but several of us brought it up. And I feel like it'd be a much better way
> forward than having a different interface for html based notifications and
> text notifications.
> (The basic idea was to accept either text or html and then if it's the
> latter and the notification scheme doesn't support it, we'd use some simple,
> specced heuristics to extract data to be used. In the thread, there were
> some specific ideas about how the transformations could work. But from a
> quick skim, I couldn't find any reasons why it was a bad idea.)
I think history has showed that "optional" features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:
"You've got mail. Click here to read it"
""
"Would you like to take our survey?"
/ Jonas
Re: [IndexedDB] IDBEvent and Event
On Fri, Jun 25, 2010 at 2:20 PM, Shawn Wilsher wrote: > Hey all, > > I think that IDBEvent needs to inherit from Event [1] in order for us to > properly inherit from EventTarget in IDBRequest. Specifically, EventTarget > takes an EventListener [2] which has a method, handleEvent, that takes an > Event object. I'm not sure this makes sense for us though, so I figured I'd > start a discussion before filing the bug. > > Cheers, > > Shawn > > [1] http://www.w3.org/TR/DOM-Level-3-Events/#interface-Event > [2] http://www.w3.org/TR/DOM-Level-3-Events/#interface-EventListener Technically I don't think inheriting from Event is required. You can generally always use language specific means of casting between interfaces. This is how for example Document [1] and DocumentTraversal [2] are related. I.e. even though you receive an Event object in handleEvent, you can always cast that to IDBEvent using whatever casting mechanism your language have. However if we want to follow the pattern used everywhere else for events [3], and I definitely think we do, then IDBEvent should indeed inherit from Event. In javascript it makes no difference as all properties from all interfaces should be directly available without any explicit casting needed. For example a returned from getElementById [4] has the functions from both Element [5] and ElementCSSInlineStyle [6] immediately available, even though getElementById returns an Element interface. [1] http://www.w3.org/TR/DOM-Level-3-Core/core.html#i-Document [2] http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#Traversal-Document [3] http://www.w3.org/TR/DOM-Level-3-Events/ [4] http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-getElBId [5] http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-745549614 [6] http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-ElementCSSInlineStyle / Jonas
Re: [IndexedDB] Atomic schema changes
On Fri, Jun 25, 2010 at 2:43 AM, Jeremy Orlow wrote:
>> > I'm OK with making createObjectStore/createIndex synchronous. It would
>> > definitely make such code cleaner and I don't see a major downside, but
>> > at
>> > the same time I feel like this API is starting to get kind of ad-hoc and
>> > unintuitive to a new user. Having the create and the remove functions
>> > completely different and in different places seems weird.
>> > So I agree with either A or leaving things as originally proposed by
>> > Jonas
>> > in "[IndexDB] Proposal for async API changes".
>>
>> Well, there's no reason not to make the same changes to
>> removeObjectStore/removeIndex. Though the more I think with this
>> design createObjectStore and removeObjectStore can stay on IDBDatabase
>> and simply throw if called outside the appropriate transaction
>> callback.
>>
>> Here is the revised proposal:
>>
>> interface IDBDatabase {
>> ...
>> IDBObjectStore createObjectStore (in DOMString name, in optional
>> DOMString keyPath, in optional boolean autoIncrement);
>> void removeObjectStore (in DOMString storeName);
>> ...
>> };
>>
>> interface IDBObjectStore {
>> ...
>> IDBIndex createIndex (in DOMString name, in DOMString keyPath, in
>> optional boolean unique);
>> IDBRequest removeIndex (in DOMString indexName);
>> ...
>> };
>>
>> Where createObjecStore/createIndex throws if a objectStore or index of
>> the given name already exists, if the keyPath has an invalid syntax,
>> or if the function is called when not inside a version-change
>> transaction callback. And removeObjectStore/removeIndex throws if the
>> objectStore or index doesn't exist or if the function is called when
>> not inside a version-change transaction callback.
>>
>> Throwing if not inside the right type of callback isn't a super clean
>> solution, but is really not that different from how add/put throws if
>> called when not inside a READ_WRITE transaction.
>
> Just to be clear, no async function (one that returns an IDBRequest) should
> _ever_ throw. (They should only call onerror.) I assume you didn't mean
> "add/put throws" literally?
Well, there's no reason we couldn't make add/put throw if called from
inside the wrong type of transaction. I guess I don't feel strongly
about it, but it seems to me that calling put from inside a READ_ONLY
transaction is a much bigger mistake than writing a duplicate key or
running out of disc space. Additionally it's a situation where we
synchronously know that there is a bug in the program.
>> > But, I feel pretty strongly that a setVersion/schema change transaction
>> > should not simply kill off anything else currently running. The reason
>> > is
>> > that it's not hard for apps to recover from a connection failing, but it
>> > is
>> > hard to handle a transaction failing in an unpredictable way.
>> > Especially
>> > static transactions (which should rarely fail committing since
>> > serialization
>> > can be guaranteed before the transaction starts).
>>
>> That might be a good idea for v1. I was planning on doing a separate
>> thread for setVersion, but maybe it's tied enough to the topic of
>> schema changes that it makes sense to bring up here.
>>
>> What I suggest is that when setVersion is called, we fire
>> 'versionchange' event on all other open IDBDatabase objects. This
>> event contains information of what the desired new version number is.
>> If no other IDBDatabase objects are open for the specific database, no
>> 'versionchange' events are fired. This allows pages using the old
>> schema version to automatically save any pending data (for example any
>> draft emails) and display UI to the user suggesting that the tab be
>> closed. If possible without dataloss, the tab could even reload itself
>> to automatically load an updated version of the page which uses the
>> new schema version.
>>
>> The 'versionchange' event would use an interface like
>>
>> interface IDBVersionEvent : IDBEvent {
>> readonly attribute string version;
>> };
>
> First of all, what I was originally advocating (sorry for not being clear)
> is that we should kill the database connection but not until all active
> transactions are complete. Though we should probably block new transactions
> from starting once setVersion is called.
> But I really like your versionchange event idea regardless. I agree that
> letting the app sync any data that might be in memory (for example, a draft
> email) is important. And the idea that the web app could refresh itself (or
> download new application code or something) seems pretty cool and useful.
> I'm fine with it firing on all frames except the one that initiated (like
> storage events). If we go with the "kill the connection once all active
> transactions are done and block new ones from starting", we'd want to start
> the blocking only after all versionchange events have finished.
> The main reason that I like the idea of not stating the version change until
> all activ
