Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2

On Jan 27, 2010, at 1:46 PM, Kris Zyp 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).

I agree with the concept. I have doubts about implementation success.  
However, I will include this in the editor's draft.

>
> * 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.

Thanks for the pointer. I will look in to this as even Pablo had  
related requirements.

>
> [1] http://wiki.commonjs.org/wiki/Promises
>
> and a comment on this:
> On 1/26/2010 1:47 PM, Pablo Castro wrote:
> > 11. API Names
>  >
>  > a.       "transaction" is really non-intuitive (particularly given
>  > the existence of currentTransaction in the same class).
>  > "beginTransaction" would capture semantics more accurately. b.
>  > ObjectStoreSync.delete: delete is a Javascript keyword, can we use
>  > "remove" instead?
> I'd prefer to keep both of these as is. Since commit and abort are
> part of the transaction interface, using transaction() to denote the
> transaction creator seems brief and appropriate. As far as
> ObjectStoreSync.delete, most JS engines have or should be contextually
> reserving "delete". I certainly prefer delete in preserving the
> familiarity of REST terminology.
>
> Thanks,
>
> - --
> Kris Zyp
> SitePen
> (503) 806-1841
> http://sitepen.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3
> X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU
> =W6Jx
> -----END PGP SIGNATURE-----
>