- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 17 Jul 2011 13:46:17 -0700
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, David Sheldon <dsheldon@microsoft.com>, John Hrvatin <John.Hrvatin@microsoft.com>
On Fri, Jul 15, 2011 at 5:55 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> Jonas,
>
> We like the concepts and principles you are proposing. It provides a more cohesive mechanism for enforcing/supporting upgrades and it leverages the existing concepts like "onversionchange" and "onblock" handlers which we are familiar with.
>
> Assuming we end up using: "IDBOpenDBRequest open (in DOMString name, in DOMString version);"
> I would like to verify the side effects:
Is there a reason you're preferring to go with the version as a
DOMString rather than as a integer as in my second proposal. I think
using a string leaves a serious problem in that people could end up
accidentally downgrading a database which could lead to things like
dataloss. Though more likely is simply bad performance as when the
downgrade happens, all other windows would if written properly close
their connection to the database.
> 1. The new open API will eliminate the need for the setVersion API.
Yes.
> 2. The new IDBOpenDBRequest will eliminate the need for the IDBVersionChangeRequest interface.
Currently IDBVersionChangeRequest is used both for setVersion and for
deleteDatabase. We certainly could use IDBOpenDBRequest for both, but
onupgrade would never fire when deleteDatabase was called.
Another alternative would be to do something like
interface IDBBlockableRequest : IDBRequest {
attribute Function onblocked;
};
interface IDBOpenDBRequest : IDBBlockableRequest {
attribute Function onupgrade;
};
Where IDBBlockableRequest is what would be returned from
deleteDatabase. But that might be a bit over engineered.
I'm fine with just having IDBOpenDBRequest if that is what people prefer.
> 3. Any time the version string in the open API doesn't match the current version string in the DB, the onupgrade handler will be called. We probably should use a different name since this will apply to upgrade and downgrade (e.g. onversionchange).
This is another reason i'm suggesting using an integer for version
instead and not having to deal with downgrading.
> 4. After the onupgrade handler is called, the onsuccess handler will be automatically called.
Yes. If the transaction created when calling the onupgrade handler is
successfully committed then the onsuccess handler is called. If,
however the transaction is aborted. The rules for when a transaction
is aborted follows the same rules as we have for
setversion-transactions today.
> 5. If the onerror handler is called (for the open API IDBRequest), the database will be in a closed state. Devs will have to call open again with a different version to re-open the db.
Yes.
> 6. These changes won't affect IDBFactory.deleteDatabase or IDBDatabase.close.
Agreed. With possible exception for what type of request to return for
IDBFactory.deleteDatabase. But the actual functionality remains
unchanged.
> 7. The changes will affect the following method and interfaces only: IDBFactory.open, IDBDatabase.setVersion, and IDBVersionChangeRequest.
Yes.
> 8. Developers won't be able to update their schemas without changing their version string.
Yes.
> Our concern is the destabilization this will introduce in the current spec and the amount of time this could take to bake. If we can scope these changes to be minimal and clearly define the areas of the spec that are affect that would ease our worries. What areas of the spec do you expect will be affected by this change? Our goal would be to minimize the side effects related to this change. How long before we can bake the concept enough to feel comfortable about its possible side effects?
>
> From our conversation with developers, they seem to be waiting for the IndexedDB spec to be locked before they start using the APIs. It would be awesome if the first version of the spec was locked soon so developers can start relying on our APIs to start using the functionality. Do you feel this will be the last major change to the spec before we can start to lock it down?
I agree with all of the above. Would love to see agreement on this as
soon as possible. We'd likely roll out the new API in firefox
nightlies in a matter of weeks after there is agreement, and in
released versions as soon as our release schedule allows us (12 weeks
or so).
/ Jonas
Received on Sunday, 17 July 2011 20:47:34 UTC