- Use of SQL means that it will be next to impossible to get agreement on the exact dialect supported by independent implementations.
- The API is extraordinarily complex that an ordinary programmer would have a hugely difficult time using it. This means more bugs will remain hidden for longer in the spec, and more bugs would be found in code using the API. The complexity arises out of a need to prevent delays when accessing a database from affecting the user interface. As a result, practically every call to the API results in an asynchronous callback.
- The API requires a lock acquisition scheme that does allows extremely limited parallelism in data access. As a result, superior implementations cannot do well. Even though the intention is noble - avoid producing exceptions as a result of deadlocks - the result is delays and timeouts as well as higher level deadlocks, which the programmer still has to deal with.
- The API has chosen to use SQL due to its well developed relational model. However, it doesn't want to provide an API that the typical database developer will be able to program against. This mythical "Web database" programmer receives undue importance in the design of the API.
- Overly reliant on SQL, when the data model in browsers is that of objects. This forces everyone to develop layers to translate between rowsets and objects.
This editor's draft of WebSimpleDB is now available from W3C. I am inviting feedback on this draft so that I can incorporate it before it goes to FPWD.