Web Data APIs

Thanks Pablo for reviewing the spec and providing valuable feedback on improving it. I have been incorporating feedback in to the editor's draft as I get it. I expect some more work before turning around and asking the WG to publish another draft. Please continue to send feedback on this DL.

My intention is to edit it in such a way that it supports a reasonable set of data access methods and provides primitives for this purpose, while also keeping the spec small (for the first version, anyway) and making the API easy to use for programmers who don't rely on any JS libraries.

On Oct 31, 2009, at 11:25 AM, Pablo Castro wrote:

We’ve been looking at the web database space here at Microsoft, trying to understand scenarios and requirements. After assessing what was out there we are forming an opinion around this. I wanted to write to this group to share how we think about the space, what principles we try to apply, and to discuss specifics.

 

The short story is that we believe Nikunj’s WebSimpleDB proposal, which basically describes a minimum-bar web database API and enables a whole set of diverse options to be built on top, is the right thing to do.

 

During the last couple of weeks we have been talking with various folks from Mozilla and Oracle and iterating over details of the WebSimpleDB draft. In the process it has become clear that we all share the same high-level expectations on the scope and capabilities of this API, and Nikunj has been hard at work making changes to the draft to keep up with them. I’ll touch on a few details below, but bear in mind that several of them are already in the process of being addressed.

 

We would love to hear feedback, requirements, specific application scenarios, etc. We want to make progress quickly and get experimental implementations going to ensure that as we explore we stay grounded, with things that are implementable.

 

 

Guiding principles and why we think the ISAM style proposed in WebSimpleDB is a good idea

As we try to understand the problem space we formulated a couple of guiding principles:

- Get into the standard the key building blocks that are either impossible to build on top, or so common that would be very redundant to do so

- Focus on an API that is simple enough that can be reliably specifiable and that can be implemented to follow the spec in a relatively simple manner

We believe that WebSimpleDB sets the stage in this direction. An ISAM layer can be used directly or can be a building block for more elaborate layers that can be built entirely in Javascript on top. Also, ISAM is simple enough that can be specified in a way that should enable highly interoperable implementations.

 

 

Trimming down

 

There are a number of elements of WebSimpleDB that we can probably live without, at least for a first version, such as Queues and Sequences. This may help simplify the database API even further.

 

Also, there are a few simplifying assumptions we can make from the get-go. For example, that “paths” as informally mentioned in the spec only reference Javascript identifiers (perhaps with dot-notation) and when used for index/primary keys they point to Javascript primitive values and not to objects/arrays.

 

 

Terminology

 

The word “Entity” has a lot of different meanings depending on who you talk to. It would be interesting to find a simpler term, perhaps something that matches the Javascript terminology better.

 

 

Areas where we need to dig deeper and have broader discussions to understand better

 

Isolation model and its implications in locking: Various isolation models lead to different failure modes; for example, regular locks mean that application code needs to be ready to deal with deadlocks, or in the case of multi-versioning you can see optimistic concurrency violation exceptions during commit. There is a tricky balance between not dictating too much from the implementation and ensuring that observable behavior across implementations really enables interoperability.

 

What’s the sweet spot for the API?: is the primary use for this API to be directly consumed by application code? Or is it a building block to create various different libraries that present a diversity of styles for query formulation and execution? We lean to the side of making it an API that’s great for libraries to build nice layers on top, but it’s still useable directly in application code (along the lines of what happens with XmlHttpRequest, where most developers will actually use a wrapper that fits the particular scenario/library better).

 

Regards,

-pablo

 

Nikunj

http://o-micron.blogspot.com