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

A few comments inline marked with [PC].

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Nikunj Mehta
Sent: Sunday, January 31, 2010 11:37 PM
To: Kris Zyp
Cc: Arthur Barstow; public-webapps
Subject: 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.

[PC] I agree with Nikunj, I suspect that a implementations will have to just compute the count, as it's unlikely that updating intermediate nodes in the tree for each update would  be desired (to try to maintain extra information for fast range size computation). At that point it's almost the same as user code iterating over the range (modulo the Javascript interface overhead). I'm also not sure how often you'd use this, as it would only work on simple conditions (no composite expressions, no functions in expressions)  that happen to have an index.

* 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.
[PC] I understand the term familiarity aspect, but this seems to be something that would just cause trouble. From a quick check with the browsers I had at hand, both IE8 and Safari 4 reject scripts where you try to add a method called "delete" to an object's prototype. Natively-implemented objects may be able to work-around this but I see no reason to push it. remove()  is probably equally intuitive. Note that the method "continue" on async cursors are likely to have the same issue as continue is also a Javascript keyword.


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

-pablo