On Sat, Mar 13, 2010 at 9:44 AM, Nikunj Mehta wrote:
>
> On Mar 12, 2010, at 9:05 AM, Aaron Boodman wrote:
>
> Looking at just this snip:
>>
>> function findFred(db) {
>> db.request.onsuccess = function() {
>> var index = db.request.result;
>> index.request.onsuccess = function() {
>> v
On Mar 12, 2010, at 9:05 AM, Aaron Boodman wrote:
Looking at just this snip:
function findFred(db) {
db.request.onsuccess = function() {
var index = db.request.result;
index.request.onsuccess = function() {
var matching = index.request.result;
if (matching)
report(match
On Mar 12, 2010, at 9:52 AM, Kris Zyp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Would it possibly be more appropriate and expedient to only provide a
sync API for now (and defer async support to possibly a later
version)?
This is entirely plausible. It is also the reason I have te
On 3/12/2010 9:52 AM, Kris Zyp wrote:
Would it possibly be more appropriate and expedient to only provide a
sync API for now (and defer async support to possibly a later
version)? It seems like the design of IndexedDB is such that most
operations should occur in O(log n) time, and probably will b
On Fri, Mar 12, 2010 at 9:52 AM, Kris Zyp wrote:
> Would it possibly be more appropriate and expedient to only provide a
> sync API for now (and defer async support to possibly a later
> version)? It seems like the design of IndexedDB is such that most
> operations should occur in O(log n) time, a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Would it possibly be more appropriate and expedient to only provide a
sync API for now (and defer async support to possibly a later
version)? It seems like the design of IndexedDB is such that most
operations should occur in O(log n) time, and probabl
I haven't been following the discussion with IndexedDB closely, but I
think the general ID of an indexed name/value store is a great idea,
and would be Good for the web.
However, I do agree with Jeremy that the current shape of the API is
too confusing. Maybe I can be useful as a new set of eyes.
