On Wed, Jan 27, 2010 at 4:46 PM, Kris Zyp <k...@sitepen.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A few comments I've been meaning to suggest: > > * count on KeyRange - Previously I had asked if there would be a way > to get a count of the number of objects within a given key range. The > addition of the KeyRange interface seems to be a step towards that, > but the cursor generated with a KeyRange still only provides a "count" > property that returns "the total number of objects that share the > current key". There is still no way to determine how many objects are > within a range. Was the intent to make "count" return the number of > objects in a KeyRange and the wording is just not up to date? > Otherwise could we add such a count property (countForRange maybe, or > have a count and countForKey, I think Pablo suggested something like > that). > > * Use promises for async interfaces - In server side JavaScript, most > projects are moving towards using promises for asynchronous interfaces > instead of trying to define the specific callback parameters for each > interface. I believe the advantages of using promises over callbacks > are pretty well understood in terms of decoupling async semantics from > interface definitions, and improving encapsulation of concerns. For > the indexed database API this would mean that sync and async > interfaces could essentially look the same except sync would return > completed values and async would return promises. I realize that > defining a promise interface would have implications beyond the > indexed database API, as the goal of promises is to provide a > consistent interface for asynchronous interaction across components, > but perhaps this would be a good time for the W3C to define such an > API. It seems like the indexed database API would be a perfect > interface to leverage promises. If you are interested in proposal, > there is one from CommonJS here [1] (the get() and call() wouldn't > apply here). With this interface, a promise.then(callback, > errorHandler) function is the only function a promise would need to > provide. > > [1] http://wiki.commonjs.org/wiki/Promises >
To piggyback on these suggestions, in prototyping a couchdb-backed store for Kris Zyp's perstore [1], which uses IndexedDB as the store API, I came across a major use case that can't be supported by the IndexedDB API as defined: couchdb's MVCC model requires an object's revision (ETag) for a DELETE. There are obviously plenty of other values (for instance, conditional HTTP header values) that could be critical -- or just very helpful -- to pass into a store's CRUD (get, put, and delete) methods. Initially we thought we could just extend the API by tacking on an *options*object to each of the CRUD method signatures but this feels hacky -- especially given that "put" has a third boolean "noOverwrite" argument defined. Would it be feasible to specify an options object for get, put and delete (which could house "noOverwrite"). Certainly the IndexedDB API cannot possibly conceive of every use case -- explicitly defining this kind of extension point would be helpful while keeping the method signatures sane. Speaking of noOverwrite, perhaps it is my unfamiliarity with WebIDL but the semantics are not entirely clear. AFAICT the overwrite characteristics of a "put" could be any of "MUST be an insert", "MUST be an update", or "insert OR update". I see that noOverwrite is defined as optional boolean which suggests it could be true, false or undefined, potentially supporting any of these three cases -- true: <insert>, false: <update>, undefined: <insert OR update>. However only the "true" case is explicitly defined as throwing on failure (MUST be an insert), implying the false|undefined case is insert OR update. This does not allow disambiguating the "MUST update" case (e.g. HTTP If-Match: *), which seems problematic, or at the very least like a missed opportunity. (Also, a bikeshed: noOverwrite seems unnecessarily convoluted -- overwrite: true <for update> | false <for insert> | undefined <for either> is a bit more intuitive.) [1] http://github.com/kriszyp/perstore
