[whatwg] SQL API and changeVersion()

[Brady Eidson]

Besides some cleanup and clarification on wording that has been  
discussed on this list, I think the spec is pretty solid - except for  
one blocker.

I think `bool changeVersion()` has a deficient design, and the content  
of its description - combined with the lack of clarity around "active"  
and "open" transactions - makes implementing it even more dubious.

First off, it is synchronous.  So it will always block on I/O.  We've  
already admitted that blocking the main thread to do I/O is very bad -  
thats why the executeSql() interface is asynchronous.  By both  
blocking on its own I/O and potentially having to wait until other  
scheduled I/O is complete, changeVersion() suffers all the  
deficiencies of doing synchronous I/O that we're trying to avoid.

But I also have some confusion about the actual intention of the  
method.  The line that is the source of most confusion -
"When the method is invoked, the user agent must obtain a full lock of  
the database (waiting for all open transactions to be closed), and  
then must verify that the current version of the database matches the  
first argument to the method."

It's easy to read this line as stating that changeVersion() needs to  
block waiting for all nested levels of executeSql() and their  
callbacks to complete, which seems nonsensical.

In addition to the whole spec needing a pass for clarification  
regarding the implicit transaction feature - points people have been  
repeatedly confused about - I propose that changeVersion() be made  
asynchronous.

Adding:
interface ChangeVersionCallback {
	void handleChangeVersion(in bool versionChanged);
};

And changing the method itself to:
void changeVersion(in DOMString oldVersion, in DOMString newVersion,  
in ChangeVersionCallback callback);

would suffice.

Thanks,
~Brady