Re: PSA: Indexed Database API is a W3C Recommendation

[Jonas Sicking]

\o/

On Thu, Jan 8, 2015 at 12:20 PM, Arthur Barstow art.bars...@gmail.com wrote:
 Congratulations All! This was a job very well done.

 On 1/8/15 2:37 PM, Coralie Mercier wrote:

 It is my pleasure to announce that Indexed Database API is published as
 a W3C Recommendation
 http://www.w3.org/TR/2015/REC-IndexedDB-20150108/

 This specification defines an API for a database of records holding
 simple values and hierarchical objects.

 All Members who responded to the Call for Review [1] of the Proposed
 Recommendation supported the publication of this specification as a
 W3C Recommendation, or abstained.

 Please join us in thanking the Web Applications Working Group [2]
 for their achievement.

 This announcement follows section 8.1.2 [3] of the W3C Process Document.

 For Tim Berners-Lee, Director,
 Philippe Le Hegaret, Interaction Domain Lead,
 Xiaoqian Wu, Team Contact,
 Yves Lafon, Team contact;
 Coralie Mercier, W3C Communications

 [1] https://www.w3.org/2002/09/wbs/33280/IndexedDB-PR/results
 [2] https://www.w3.org/2008/webapps/
 [3] https://www.w3.org/2014/Process-20140801/#ACReviewAfter

PSA: Indexed Database API is a W3C Recommendation

[Arthur Barstow]

Congratulations All! This was a job very well done.

On 1/8/15 2:37 PM, Coralie Mercier wrote:

It is my pleasure to announce that Indexed Database API is published as
a W3C Recommendation
http://www.w3.org/TR/2015/REC-IndexedDB-20150108/

This specification defines an API for a database of records holding
simple values and hierarchical objects.

All Members who responded to the Call for Review [1] of the Proposed
Recommendation supported the publication of this specification as a
W3C Recommendation, or abstained.

Please join us in thanking the Web Applications Working Group [2]
for their achievement.

This announcement follows section 8.1.2 [3] of the W3C Process Document.

For Tim Berners-Lee, Director,
Philippe Le Hegaret, Interaction Domain Lead,
Xiaoqian Wu, Team Contact,
Yves Lafon, Team contact;
Coralie Mercier, W3C Communications

[1] https://www.w3.org/2002/09/wbs/33280/IndexedDB-PR/results
[2] https://www.w3.org/2008/webapps/
[3] https://www.w3.org/2014/Process-20140801/#ACReviewAfter

Re: [testing] Seeking Test Facilitator(s) for Indexed Database API

[Arthur Barstow]

On 11/26/13 1:45 AM, ext Zhang, Zhiqiang wrote:

From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Saturday, November 23, 2013 2:58 AM
Please contact me if you can commit to helping with this effort and you
have `relevant` experience.

After reconsidering your invitation at TPAC about this, I would like to take 
this role and to review the submissions from next week.


This is excellent Zhiqiang, thanks! (I updated PubStatus accordingly.)


BTW, I will backup Tina Zhao, the Test Facilitator for Server Sent Events, for 
about half a year during her maternity leave. Please contact me if you have any 
matters related to SSE.


OK, thanks for your help here. Good luck Tina!

-Cheers, ArtB

RE: [testing] Seeking Test Facilitator(s) for Indexed Database API

[Zhang, Zhiqiang]

 From: Arthur Barstow [mailto:art.bars...@nokia.com]
 Sent: Saturday, November 23, 2013 2:58 AM

 Please contact me if you can commit to helping with this effort and you
 have `relevant` experience.

After reconsidering your invitation at TPAC about this, I would like to take 
this role and to review the submissions from next week.

BTW, I will backup Tina Zhao, the Test Facilitator for Server Sent Events, for 
about half a year during her maternity leave. Please contact me if you have any 
matters related to SSE.

Thanks,
Zhiqiang

[testing] Seeking Test Facilitator(s) for Indexed Database API

[Arthur Barstow]

[ Bcc: public-webapps-testsuite ]

Hi All,

We need help with the Indexed Database API testing effort. The general 
expectations for a Test Facilitator (TF) are defined in the testing 
Roles wiki [Roles]. For this spec, one of the first steps is to review 
the various submissions and recommend the set of tests WebApps should 
use to test the [CR] (and identify high priority gaps if there are any). 
After we have agreement on this set, those tests will need to be 
reviewed and the review can be done by multiple people.


Group submissions:

* Opera: https://github.com/w3c/web-platform-tests/pull/63
* Microsoft: https://github.com/w3c/web-platform-tests/pull/64
* Ms2ger: https://github.com/w3c/web-platform-tests/pull/65

TestTTWF Paris submissions:

* BaptisteFontaine: https://github.com/w3c/web-platform-tests/pull/66
* ChristopheCharles: https://github.com/w3c/web-platform-tests/pull/67
* dgrogan: https://github.com/w3c/web-platform-tests/pull/68
* rhuet: https://github.com/w3c/web-platform-tests/pull/69

Please contact me if you can commit to helping with this effort and you 
have `relevant` experience.


-Thanks, ArtB

[Roles] http://www.w3.org/wiki/Webapps/Submitting_tests#Testing_Roles
[CR] http://www.w3.org/TR/2013/CR-IndexedDB-20130704/


 Original Message 
Subject: 	ACTION-704: Find another test facilitator for idb spec (Web 
Applications Working Group)

Date:   Tue, 12 Nov 2013 03:13:17 +
From: 	ext Web Applications Working Group Issue Tracker 
sysbot+trac...@w3.org

Reply-To:   Web Applications Working Group public-webapps@w3.org
To: art.bars...@nokia.com



ACTION-704: Find another test facilitator for idb spec (Web Applications 
Working Group)

http://www.w3.org/2008/webapps/track/actions/704

On: Arthur Barstow
Due: 2013-11-19

If you do not want to be notified on new action items for this group, please 
update your settings at:
http://www.w3.org/2008/webapps/track/users/7672#settings

For a deeper Indexed Database API (nested ObjectStores)

[Michaël Rouges]

Hello,

I recently experimented with this API trying to simulate a file system, but
I am sad to see a lack of depth.

To preserve the environment applications using my tool, I want to create
only one database for my filesystem.

So I create my database, I add a table representing a folder and I save my
files, until this point, it's ok.

The design problem is when I have to simulate a subfolder ...

I then create another database, but it does not seem very clean because the
user of the application should be able to create your own folders,
subfolders and files, and the application using my tool should also be able
to create their own databases data ... there is therefore a risk of
conflict.

Using only one database should therefore go through the creation of a table
folder or subfolder.

Ok, it's doable ... However, it would ruin the performance, because when
you open a database, the API returns an object containing the
objectStoreNames property that contains the list of all tables in the
database.

Assuming that my file system contains thousands of folders and sub-folders,
once the database is opened, the API will have to recover the full list,
while operations to this file system in perhaps one or two concern.

I can store objects in the records of my tables but this would retrieve an
object that can be huge, again, while operations to this file system can be
a concern or two.

None of these solutions seem to me, at once, clean and optimal in terms of
resources.

My idea is that it may be more optimal to save a table in the fields of a
record in another table and could overcome the lack of relationships.

Since a picture is better than a long explanation, here is an example
schema ObjectStores nested:

indexedDB = {
database: {
directory_0: {
subdirectory: {
// ...
}
},
directory_1: {
// ...
},
file_0.txt,
file_1.txt
}
}

For additional and / or feedback information, do not hesitate to contact me.
;)

Michaël

RE: For a deeper Indexed Database API (nested ObjectStores)

[Aaron Powell]

It’s an interesting problem that you’re trying to solve and I’ve had a crack at 
my own implementation which you can find here - 
https://github.com/aaronpowell/indexeddb-filesystem

A few implementation points:

-  I don’t think you want to split across multiple objectStores in your 
database, that’ll make it very slow to query as can’t build up indexes

-  My implementation is a flat structure which you have parent IDs 
tracked against each object so you’re building up a tree of sorts in your 
database

-  While I haven’t implemented it (at present) to get back the contents 
of a folder you would do something like:

var transaction = db.transaction(storeName);
var store = transaction.objectStore(storeName);
var index = store.index(‘parent’);
var range = IDBKeyRange.only(parent id);

index.openCursor(range).onsuccess = function (e) {
  //track items that the cursor gets
};


-  You could also look at doing stuff like using array indexes to store 
the full parent path which you can then query across

Anyway I might keep playing with my implementation to see how it turns out.


Aaron Powell
MVP - Internet Explorer (Development) | FunnelWeb Team 
Memberhttp://funnelweblog.com/

http://apowell.mehttp://apowell.me/ | http://twitter.com/slace | Skype: 
aaron.l.powell | Githubhttp://github.com/aaronpowell/ | 
BitBuckethttp://hg.apwll.me/

From: Michaël Rouges [mailto:michael.rou...@gmail.com]
Sent: Monday, 22 April 2013 5:31 PM
To: public-webapps@w3.org
Subject: For a deeper Indexed Database API (nested ObjectStores)

Hello,

I recently experimented with this API trying to simulate a file system, but I 
am sad to see a lack of depth.

To preserve the environment applications using my tool, I want to create only 
one database for my filesystem.

So I create my database, I add a table representing a folder and I save my 
files, until this point, it's ok.

The design problem is when I have to simulate a subfolder ...

I then create another database, but it does not seem very clean because the 
user of the application should be able to create your own folders, subfolders 
and files, and the application using my tool should also be able to create 
their own databases data ... there is therefore a risk of conflict.

Using only one database should therefore go through the creation of a table 
folder or subfolder.

Ok, it's doable ... However, it would ruin the performance, because when you 
open a database, the API returns an object containing the objectStoreNames 
property that contains the list of all tables in the database.

Assuming that my file system contains thousands of folders and sub-folders, 
once the database is opened, the API will have to recover the full list, while 
operations to this file system in perhaps one or two concern.

I can store objects in the records of my tables but this would retrieve an 
object that can be huge, again, while operations to this file system can be a 
concern or two.

None of these solutions seem to me, at once, clean and optimal in terms of 
resources.

My idea is that it may be more optimal to save a table in the fields of a 
record in another table and could overcome the lack of relationships.

Since a picture is better than a long explanation, here is an example schema 
ObjectStores nested:

indexedDB = {
database: {
directory_0: {
subdirectory: {
// ...
}
},
directory_1: {
// ...
},
file_0.txt,
file_1.txt
}
}

For additional and / or feedback information, do not hesitate to contact me. ;)
Michaël

Re: For a deeper Indexed Database API (nested ObjectStores)

[Eric Bidelman]

Hi Michaël,

I also implemented a filesystem solution on top of IDB:
https://github.com/ebidel/idb.filesystem.js/blob/master/src/idb.filesystem.js

It's a polyfill for the W3C Filesystem API [1]. The abstraction is nice
because it
takes away the hairy details (as you've encountered) of trying to use IDB
as a filesystem.

My approach was similar to Aaron's. There's only one database and one
object store.
Subfolders are implemented by saving files keyed off their fullPath and
cleverly using IDBKeyRanges.bound. Something like:

var DIR_SEPARATOR = '/';
var OPEN_BOUND = String.fromCharCode(DIR_SEPARATOR.charCodeAt(0) + 1);
var fullPath =  '/path/to/folder/';
IDBKeyRange.bound(fullPath, fullPath + OPEN_BOUND , false, true);

restricts the results in such a way that the keys that are returned only
fall under the
virtual folder /path/to/folder/.

Hope that helps. There's a demo here Demo:
http://html5-demos.com/static/filesystem/idb.filesystem.js/demos/basic/index.html
if
you're interested.

[1]: http://www.w3.org/TR/file-system-api/


On Mon, Apr 22, 2013 at 2:13 AM, Aaron Powell m...@aaron-powell.com wrote:

  It’s an interesting problem that you’re trying to solve and I’ve had a
 crack at my own implementation which you can find here -
 https://github.com/aaronpowell/indexeddb-filesystem

 ** **

 A few implementation points:

 **-  **I don’t think you want to split across multiple
 objectStores in your database, that’ll make it very slow to query as can’t
 build up indexes

 **-  **My implementation is a flat structure which you have
 parent IDs tracked against each object so you’re building up a tree of
 sorts in your database

 **-  **While I haven’t implemented it (at present) to get back
 the contents of a folder you would do something like:

 ** **

 var transaction = db.transaction(storeName);

 var store = transaction.objectStore(storeName);

 var index = store.index(‘parent’);

 var range = IDBKeyRange.only(parent id);

 ** **

 index.openCursor(range).onsuccess = function (e) {

   //track items that the cursor gets

 };

 ** **

 **-  **You could also look at doing stuff like using array
 indexes to store the full parent path which you can then query across

 ** **

 Anyway I might keep playing with my implementation to see how it turns out.
 

 ** **

 ** **

 Aaron Powell
 MVP - Internet Explorer (Development) | FunnelWeb Team 
 Memberhttp://funnelweblog.com/

 http://apowell.me | http://twitter.com/slace | Skype: aaron.l.powell |
 Github http://github.com/aaronpowell/ | BitBucket http://hg.apwll.me/
 

 ** **

 *From:* Michaël Rouges [mailto:michael.rou...@gmail.com]
 *Sent:* Monday, 22 April 2013 5:31 PM
 *To:* public-webapps@w3.org
 *Subject:* For a deeper Indexed Database API (nested ObjectStores)

 ** **

 Hello,

 I recently experimented with this API trying to simulate a file system,
 but I am sad to see a lack of depth.

 To preserve the environment applications using my tool, I want to create
 only one database for my filesystem.

 So I create my database, I add a table representing a folder and I save my
 files, until this point, it's ok.

 The design problem is when I have to simulate a subfolder ...

 I then create another database, but it does not seem very clean because
 the user of the application should be able to create your own folders,
 subfolders and files, and the application using my tool should also be able
 to create their own databases data ... there is therefore a risk of
 conflict.

 Using only one database should therefore go through the creation of a
 table folder or subfolder.

 Ok, it's doable ... However, it would ruin the performance, because when
 you open a database, the API returns an object containing the
 objectStoreNames property that contains the list of all tables in the
 database.

 Assuming that my file system contains thousands of folders and
 sub-folders, once the database is opened, the API will have to recover the
 full list, while operations to this file system in perhaps one or two
 concern.

 I can store objects in the records of my tables but this would retrieve an
 object that can be huge, again, while operations to this file system can be
 a concern or two.

 None of these solutions seem to me, at once, clean and optimal in terms of
 resources.

 My idea is that it may be more optimal to save a table in the fields of a
 record in another table and could overcome the lack of relationships.

 Since a picture is better than a long explanation, here is an example
 schema ObjectStores nested:

 indexedDB = {
 database: {
 directory_0: {
 subdirectory: {
 // ...
 }
 },
 directory_1: {
 // ...
 },
 file_0.txt,
 file_1.txt
 }
 }

 For additional and / or feedback information, do not hesitate to contact
 me. ;)

 Michaël

Re: For a deeper Indexed Database API (nested ObjectStores)

[Michaël Rouges]

Thank you to you for your answers.

I watched your codes and, in my opinion, this kind of operation is much
heavier than it should.

Plus there are any files on the system, the operation will require more
treatments.

My idea would have the advantage of dividing the system into smaller
sections (one for each folder / subfolder).

I will continue to work my code to illustrate my vision of it and I will
share it soon. ;)


Michaël

Re: CfC: publish new WD of Indexed Database API; deadline Oct 21

[Arthur Barstow]

Hi All - although this CfC passed, for various reasons the WD was not 
published before TPAC. However, yesterday, Jonas and Eliot prepared a WD 
that is now queued for publishing on Dec 6:


   
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview-WD-06-December-2011.html


On 10/14/11 4:04 PM, ext Arthur Barstow wrote:
This is a Call for Consensus to publish a new Working Draft of the 
Indexed Database API spec (last published 19-Apr-2011):


http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

Re: Indexed database API autoIncrement

[Jonas Sicking]

On Sunday, November 13, 2011, Shawn Wilsher m...@shawnwilsher.com wrote:
 On 10/23/2011 3:04 PM, Jonas Sicking wrote:

 Good catch! This definitely needs to be specified in the spec.

 I have a weak preference for using 1. This has a smaller risk of
 triggering edge cases in the client code since it's always truthy.
 I.e. if someone tries to detect the presence of an id, they won't fail
 due to the id being 0.

 Looks like there was a [loose] consensus around one, but it's not
specified as far as I can tell.  Should I file a bug or will it get
magically fixed with this e-mail?

Please file bug.

/ Jonas

RE: Indexed database API autoIncrement

[Israel Hilerio]

On October 23, 2011 3:19 PM, Charles Pritchard wrote:
 On Oct 23, 2011, at 3:04 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano i...@html5.jp wrote:
  Hello everyone,
 
  I'm not a W3C member, can I send a mail to the list?
 
  Absolutely! This is a public list intended for just that!
 
  I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
  I found a different behavior between the two.
  I set autoIncrement to true when I created a Object Store as below.
 
  var store = db.createObjectStore(store_name, { keyPath: 'id',
  autoIncrement: true });
 
  Then, I added some records.
 
  IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set 
  it
 to 1.
  Which is correct?
  I couldn't find the definition about this in the spec.
  The first value of autoIncrement should be defined in the spec, or
  the spec should allow us to set the first value of autoIncrement, I think.
 
  Sorry in advance if the discussion has already been done.
  Thank you for your time.
 
  Good catch! This definitely needs to be specified in the spec.
 
  I have a weak preference for using 1. This has a smaller risk of
  triggering edge cases in the client code since it's always truthy.
  I.e. if someone tries to detect the presence of an id, they won't fail
  due to the id being 0.
 
 I agree -- this is also the behavior in all DBMS I've worked with. There's 
 time
 for MS to update their implementation. All around win.

We are aware of the issue and we're looking to fix the problem to be 
interoperable.  
Thanks for the feedback.

Israel

Indexed database API autoIncrement

[Futomi Hatano]

Hello everyone,

I'm not a W3C member, can I send a mail to the list?

I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
I found a different behavior between the two.
I set autoIncrement to true when I created a Object Store as below.

var store = db.createObjectStore(store_name, { keyPath: 'id', autoIncrement: 
true });

Then, I added some records.

IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set it to 
1.
Which is correct?
I couldn't find the definition about this in the spec.
The first value of autoIncrement should be defined in the spec, 
or the spec should allow us to set the first value of autoIncrement, I think.

Sorry in advance if the discussion has already been done.
Thank you for your time.

-- 
Futomi Hatano i...@html5.jp
http://www.html5.jp/
http://www.futomi.com/
http://twitter.com/futomi

Re: Indexed database API autoIncrement

[Kyle Huey]

On Sun, Oct 23, 2011 at 7:20 AM, Futomi Hatano i...@html5.jp wrote:

 Hello everyone,

 I'm not a W3C member, can I send a mail to the list?


Yes, this mailing list is open to anyone.

I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
 I found a different behavior between the two.
 I set autoIncrement to true when I created a Object Store as below.

 var store = db.createObjectStore(store_name, { keyPath: 'id',
 autoIncrement: true });

 Then, I added some records.

 IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set
 it to 1.
 Which is correct?


This is a good question.  I don't believe that the spec specifies this.

- Kyle

Re: Indexed database API autoIncrement

[Jonas Sicking]

On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano i...@html5.jp wrote:
 Hello everyone,

 I'm not a W3C member, can I send a mail to the list?

Absolutely! This is a public list intended for just that!

 I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
 I found a different behavior between the two.
 I set autoIncrement to true when I created a Object Store as below.

 var store = db.createObjectStore(store_name, { keyPath: 'id', autoIncrement: 
 true });

 Then, I added some records.

 IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set it 
 to 1.
 Which is correct?
 I couldn't find the definition about this in the spec.
 The first value of autoIncrement should be defined in the spec,
 or the spec should allow us to set the first value of autoIncrement, I think.

 Sorry in advance if the discussion has already been done.
 Thank you for your time.

Good catch! This definitely needs to be specified in the spec.

I have a weak preference for using 1. This has a smaller risk of
triggering edge cases in the client code since it's always truthy.
I.e. if someone tries to detect the presence of an id, they won't fail
due to the id being 0.

/ Jonas

Re: Indexed database API autoIncrement

[Charles Pritchard]

On Oct 23, 2011, at 3:04 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Sun, Oct 23, 2011 at 4:20 AM, Futomi Hatano i...@html5.jp wrote:
 Hello everyone,
 
 I'm not a W3C member, can I send a mail to the list?
 
 Absolutely! This is a public list intended for just that!
 
 I've tried to use Indexed database API using IE10 PP3 and Chrome 16 dev.
 I found a different behavior between the two.
 I set autoIncrement to true when I created a Object Store as below.
 
 var store = db.createObjectStore(store_name, { keyPath: 'id', autoIncrement: 
 true });
 
 Then, I added some records.
 
 IE10 PP3 set the key value of the first recored to 0, while Chrome 16 set it 
 to 1.
 Which is correct?
 I couldn't find the definition about this in the spec.
 The first value of autoIncrement should be defined in the spec,
 or the spec should allow us to set the first value of autoIncrement, I think.
 
 Sorry in advance if the discussion has already been done.
 Thank you for your time.
 
 Good catch! This definitely needs to be specified in the spec.
 
 I have a weak preference for using 1. This has a smaller risk of
 triggering edge cases in the client code since it's always truthy.
 I.e. if someone tries to detect the presence of an id, they won't fail
 due to the id being 0.

I agree -- this is also the behavior in all DBMS I've worked with. There's time 
for MS to update their implementation. All around win.

CfC: publish new WD of Indexed Database API; deadline Oct 21

[Arthur Barstow]

This is a Call for Consensus to publish a new Working Draft of the 
Indexed Database API spec (last published 19-Apr-2011):


http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

Agreement to the proposal: a) indicates support for publishing a new WD; 
and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps by October 21 at the latest.


As with all of our CfCs, positive response is preferred and encouraged 
and silence will be assumed to be agreement with the proposal.


FYI, the open bug list for this spec is at [1].

-AB

[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Indexed%20Database%20APIresolution=---

Re: CfC: publish new WD of Indexed Database API; deadline Oct 21

[Charles McCathieNevile]

On Fri, 14 Oct 2011 22:04:06 +0200, Arthur Barstow art.bars...@nokia.com  
wrote:


This is a Call for Consensus to publish a new Working Draft of the  
Indexed Database API spec (last published 19-Apr-2011):


Yes please.

cheers


http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

Agreement to the proposal: a) indicates support for publishing a new WD;  
and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please send  
them to public-webapps by October 21 at the latest.


As with all of our CfCs, positive response is preferred and encouraged  
and silence will be assumed to be agreement with the proposal.


FYI, the open bug list for this spec is at [1].

-AB

[1]  
http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Indexed%20Database%20APIresolution=---






--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: publish new Working Draft of Indexed Database API; deadline April 16

[timeless]

On Tue, Apr 19, 2011 at 6:41 PM, Eliot Graff eliot.gr...@microsoft.com wrote:
 Thanks for the feedback. Moving forward, I will track changes and resolution 
 of these suggestions in bug 9379 [1].

ok

 Appreciate the time you've spent on this.

here's next next part, note that i drafted it a while ago and am just
sending it to flush my mailbox.

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

part two...

 The transaction mode determines both which operations are allowed
 to be performed during the transaction, as well whether two transactions
 can run concurrently or not.


The transaction mode controls whether or not multiple transactions can
run currently and
which operations may be performed during the transaction.

 Which operations are allowed be be performed are

The allowed operations are

 defined in detail below,
 but in general transactions opened in READ_ONLY mode are only allowed
 to perform reading operations which does not change data.

s/reading //
s/does/do/

-- this defines read, and operations are plural.. if you really want
to define it perhaps stick some quotes around reading?

 READ_WRITE transactions are allowed to

 perform reading and writing transactions to existing object stores,

s/perform reading and writing/read from and write/

 where as VERSION_CHANGE transactions are allowed to perform any operations, 
 including ones that delete and create object stores and indexes.

 As long as the VERSION_CHANGE transaction, the implementation

s/transaction/transaction is pending/
?

 MUST wait with starting any other transactions against the same

s/with/before/

 database until the VERSION_CHANGE transaction is finished.

 There are a number of ways that an implementation ensure this.

s/ensure/ensures/

 It can prevent READ_WRITE transactions whose scope overlap

s/prevent/stall/
?
(you don't prevent them from ever existing, you at best prevent them
from starting which seems more like stalling or delaying)

s/overlap/overlaps/

 the scope of the READ_ONLY transaction from starting until the
 READ_ONLY transaction is finished.

s/is finished/finishes/

 Or it can allow the READ_ONLY transaction to see a snapshot of the
 contents of the object stores which is taken when the READ_ONLY
 transaction is started.

s/is //

 Similarly, implementations MUST ensure that a READ_WRITE transaction is only 
 affected by changes to object stores that are made using the transaction 
 itself. I.e. the implementation MUST ensure that another transaction does not 
 modify the contents of object stores in the READ_WRITE transactions scope.

I don't think starting a sentence with i.e. is a good idea...

s/transactions/transaction's/

 The implementation MUST also ensure that if the READ_WRITE transaction
 completes successfully, that the changes written to object stores using the

s/, that / /

 transaction can be committed to the database without merge conflicts.

i find can be here problematic, i know it's only meaningful with the
next sentence, but i don't think it works well.

 An implementation MUST NOT abort a transaction due to merge conflicts.


 An implementation MUST NOT start any transaction until all other
 READ_WRITE transactions with overlapping scope have completed.

doesn't this prevent merge conflicts?

 When multiple transactions are eligible to be started, older transactions
 should be started first.

should 'should' be written as an RFC word?

 User agents MUST ensure a reasonable level of fairness across transactions to 
 prevent starvation.
 For example if multiple READ_ONLY transaction are started one after another 
 the implementation MUST ensure that that doesn't indefinitely prevent a 
 pending READ_WRITE transaction from starting.

This MUST doesn't seem testable, and sticking a MUST into an example
seems wrong.

 Transaction objects implement

Each transaction object will implement either

 the IDBTransaction or the IDBTransactionSync

 interfaces.

interface.

-- this is a style change and applies to other objects in this
document. I'm assuming that an object only ever implements one of the
two interfaces and thus interface should be singular and you should
spell out that it's exclusive. If it isn't, I'd like to know how/why.

 Every request also has a result and an errorCode, neither of which are 
 accessible until the done flag is set to true.

does 'are accessible' mean will throw an exception if poked?

 Finally, requests have a request transaction. When a request is created, it 
 is always placed against a transaction using either the steps to a 
 asynchronously execute a request or the steps to a synchronously execute a 
 request.

It would be really helpful if things like steps to whatever were links

 This sets the request transaction to be that request.

s/This sets/Those steps set/

 The only exceptions to this are the request returned from a IDBFactory.open 
 call and the request returned from a IDBDatabase.setVersion call, which 
 create requests 

RE: publish new Working Draft of Indexed Database API; deadline April 16

[Eliot Graff]

Hi Josh.

Thanks for the feedback. Moving forward, I will track changes and resolution of 
these suggestions in bug 9379 [1].

Appreciate the time you've spent on this.

Eliot

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9739



 -Original Message-
 From: public-webapps-requ...@w3.org [mailto:public-webapps-
 requ...@w3.org] On Behalf Of timeless
 Sent: Tuesday, April 12, 2011 12:32 AM
 To: Arthur Barstow
 Cc: public-webapps
 Subject: Re: publish new Working Draft of Indexed Database API; deadline
 April 16
 
 On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com
 wrote:
   http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
 
 I expect this message to only have editorial comments. However, I'm not
 fond of April 16th, this month is tax month and I still need to file.
 
  Transaction
  A transaction is used to interact with the data in a database.
  Whenever data is read or written to the database this is done using a
 transaction.
 
 maybe s/this/it/
 
  All transactions are created using a connection,
 
 I don't like using, perhaps from? -- I haven't gotten to the API yet.
 I'm also uncertain about 'a connection' vs. 'connections'
 
  which is the transactions connection.
 
 s/transactions/transaction's/
 
  The transaction has a mode which determines which types of
  interactions can be performed using the transaction.
 
 s/using the transaction/upon it/ ? -- The transaction also started the
 sentence.
 
  The mode is set when the transaction is created and remains constant
  for the
 
 s/constant/fixed/
 
  lifetime of the transaction.
 
 s/lifetime/life/
 
  The transaction also has a scope which determines which object stores
  the transaction can interact with.
 
 s/which.*with/the object stores with which the transaction may interact/.
 
  Finally, transactions have a active flag,
 
 s/ a / an /
 s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next 
 sentence.
 
  which determines if new requests can currently be placed against the
 transaction.
 
 The prose here implies that this is mutable, it's also awkward (probably he
 use of 'currently').
 
  Finally, transactions also contain a request list of requests which have 
  been
 placed against the transaction.
 
 It seems that placed is treated as technical language, I'd expect it to be
 defined somewhere (or globally replaced by 'made').
 
  Transactions have a constant scope which is determined when the
  transaction is created and remains constant for the lifetime of the
 transaction.
 
 Each transaction has a fixed scope determined at creation time.
 
  Transactions offer some protection from application and system failures.
 
   A transaction represents an atomic and durable set of data access and
 mutation operations.
 
 I know that data can be uncountable or plural, but I'm unsure that 'access'
 fits with its use here -- should it be 'accesses'?
 
  This is encouraged using the automatically committing functionality
 described below.
 
 s/using the automatically/by the automatic/
 
  Authors can still cause transactions to run for a long time, however
  this is generally not a usage pattern which is recommended
 
 s/usage pattern which is recommended/a recommended usage pattern/
 
  and can lead to bad user experience in some implementations.
 
 possibly a bad user experience | bad user experiences ?
 
  A transaction is created using IDBDatabase.transaction.
  The arguments passed determine what the scope of the transaction is
 
 s/what//; s/is//
 
  and whether it's read only or not.
 
 whether or not it is read-only.
 
  When a transaction is created its active flag is initially set to true.
 
  The implementation MUST allow requests to be placed against the
  transaction whenever the active flag is true.
 
  This is the case even if the transaction has not yet been started.
 
  Until the transaction is started the implementation MUST NOT execute
  these requests, but the implementation MUST still keep track of the
  requests and their order.
 
 s/, but/;/
 s/still//
 
  Requests may only be placed against the transaction
 
 s/the/a/
 
  while the transaction is active.
 
 s/the transaction/it/
 
  If a request is attempted to be placed against a transaction when
 
 I find request/attempted/placed awkward, possibly because it lacks an
 actor...
 
  it is not active,
 
 I believe not active is used here to be the technical state not active,
 perhaps it should be marked up. Otherwise as this is prose, I'd use 
 inactive.
 
  the implementation MUST reject the attempt by throwing a
 TRANSACTION_INACTIVE_ERR exception.
 
 Inactive is used in the exception type, it's a valid English word
 
  Once an implementation is able to enforce the constraints defined for
  the mode of the transaction,
 
 transaction mode
 
  defined below, the implementation MUST asynchronously start the
 transaction.
 
  When this happens is affected by the mode in which the transaction is
  opened, and which

Re: publish new Working Draft of Indexed Database API; deadline April 16

[timeless]

On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com wrote:
  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

I expect this message to only have editorial comments. However, I'm
not fond of April 16th, this month is tax month and I still need to
file.

 Transaction
 A transaction is used to interact with the data in a database. Whenever data 
 is read or written to the
 database this is done using a transaction.

maybe s/this/it/

 All transactions are created using a connection,

I don't like using, perhaps from? -- I haven't gotten to the API yet.
I'm also uncertain about 'a connection' vs. 'connections'

 which is the transactions connection.

s/transactions/transaction's/

 The transaction has a mode which determines which types of interactions can
 be performed using the transaction.

s/using the transaction/upon it/ ? -- The transaction also started
the sentence.

 The mode is set when the transaction is created and remains constant for the

s/constant/fixed/

 lifetime of the transaction.

s/lifetime/life/

 The transaction also has a scope which determines
 which object stores the transaction can interact with.

s/which.*with/the object stores with which the transaction may interact/.

 Finally, transactions have a active flag,

s/ a / an /
s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the
next sentence.

 which determines if new requests can currently be placed against the 
 transaction.

The prose here implies that this is mutable, it's also awkward
(probably he use of 'currently').

 Finally, transactions also contain a request list of requests which have been 
 placed against the transaction.

It seems that placed is treated as technical language, I'd expect it
to be defined somewhere (or globally replaced by 'made').

 Transactions have a constant scope which is determined when the transaction
 is created and remains constant for the lifetime of the transaction.

Each transaction has a fixed scope determined at creation time.

 Transactions offer some protection from application and system failures.

  A transaction represents an atomic and durable set of data access and 
 mutation operations.

I know that data can be uncountable or plural, but I'm unsure that
'access' fits with its use here -- should it be 'accesses'?

 This is encouraged using the automatically committing functionality described 
 below.

s/using the automatically/by the automatic/

 Authors can still cause transactions to run for a long time, however this is 
 generally not a usage pattern which is recommended

s/usage pattern which is recommended/a recommended usage pattern/

 and can lead to bad user experience in some implementations.

possibly a bad user experience | bad user experiences ?

 A transaction is created using IDBDatabase.transaction.
 The arguments passed determine what the scope of the transaction is

s/what//; s/is//

 and whether it's read only or not.

whether or not it is read-only.

 When a transaction is created its active flag is initially set to true.

 The implementation MUST allow requests to be placed against the
 transaction whenever the active flag is true.

 This is the case even if the transaction has not yet been started.

 Until the transaction is started the implementation MUST NOT
 execute these requests, but the implementation MUST still keep
 track of the requests and their order.

s/, but/;/
s/still//

 Requests may only be placed against the transaction

s/the/a/

 while the transaction is active.

s/the transaction/it/

 If a request is attempted to be placed against a transaction when

I find request/attempted/placed awkward, possibly because it lacks an actor...

 it is not active,

I believe not active is used here to be the technical state not
active, perhaps it should be marked up. Otherwise as this is prose,
I'd use inactive.

 the implementation MUST reject the attempt by throwing a 
 TRANSACTION_INACTIVE_ERR exception.

Inactive is used in the exception type, it's a valid English word

 Once an implementation is able to enforce the constraints defined for the
 mode of the transaction,

transaction mode

 defined below, the implementation MUST asynchronously start the transaction.

 When this happens is affected by the mode in which the transaction
 is opened, and which object stores are included in scope of the transaction.

s/which/the/
s/are//
s/scope of the transaction/the transaction's scope/

 Once the transaction has been started the implementation can start executing 
 the requests placed against the transaction.
 Unless otherwise defined requests MUST be executed in the order
 they are placed against the transaction.

s/they/in which they/
s/are/were/

I find placed against strange. made against seems to work
Otherwise placed into

 Likewise, their result MUST be returned in the order
 the request was placed against a specific transaction.

result appears to be used as a mass noun, but request is singular,
I'm pretty 

RE: publish new Working Draft of Indexed Database API; deadline April 16

[Adrian Bateman]

On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote:
 The Editors of the Indexed Database API would like to publish a new
 Working Draft of their spec and this is a Call for Consensus to do so:
 
   http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
 
 If one agrees with this proposal, it: a) indicates support for
 publishing a new WD; and b) does not necessarily indicate support for
 the contents of the WD.
 
 If you have any comments or concerns about this proposal, please send
 them to public-webapps by April 16 at the latest.
 
 As with all of our CfCs, positive response is preferred and encouraged
 and silence will be assumed to be agreement with the proposal.

Microsoft supports this.

CfC: publish new Working Draft of Indexed Database API; deadline April 16

[Arthur Barstow]

The Editors of the Indexed Database API would like to publish a new 
Working Draft of their spec and this is a Call for Consensus to do so:


 http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

If one agrees with this proposal, it: a) indicates support for 
publishing a new WD; and b) does not necessarily indicate support for 
the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps by April 16 at the latest.


As with all of our CfCs, positive response is preferred and encouraged 
and silence will be assumed to be agreement with the proposal.


-Art Barstow

Re: CfC: publish new Working Draft of Indexed Database API; deadline April 16

[Tab Atkins Jr.]

On Sat, Apr 9, 2011 at 4:22 AM, Arthur Barstow art.bars...@nokia.com wrote:
 The Editors of the Indexed Database API would like to publish a new Working
 Draft of their spec and this is a Call for Consensus to do so:

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If one agrees with this proposal, it: a) indicates support for publishing a
 new WD; and b) does not necessarily indicate support for the contents of the
 WD.

 If you have any comments or concerns about this proposal, please send them
 to public-webapps by April 16 at the latest.

 As with all of our CfCs, positive response is preferred and encouraged and
 silence will be assumed to be agreement with the proposal.

I support publishing this document.

~TJ

Re: CfC: publish new Working Draft of Indexed Database API; deadline April 16

[Jonas Sicking]

I support this.

On Sat, Apr 9, 2011 at 4:22 AM, Arthur Barstow art.bars...@nokia.com wrote:
 The Editors of the Indexed Database API would like to publish a new Working
 Draft of their spec and this is a Call for Consensus to do so:

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If one agrees with this proposal, it: a) indicates support for publishing a
 new WD; and b) does not necessarily indicate support for the contents of the
 WD.

 If you have any comments or concerns about this proposal, please send them
 to public-webapps by April 16 at the latest.

 As with all of our CfCs, positive response is preferred and encouraged and
 silence will be assumed to be agreement with the proposal.

 -Art Barstow

RE: Indexed Database API

[Pablo Castro]

From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Jeremy Orlow
Sent: Tuesday, March 15, 2011 3:08 PM

 Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310

I'm not sure if this is a lot more valuable than just creating an index over 
whatever index key you want plus the primary key, and then seeking to the 
compound key of the last row in the previous page to resume scanning the next 
page of records. No strong pushback, just not sure this is worth the extra 
method.

-pablo

Re: Indexed Database API

[Jonas Sicking]

On Thu, Mar 17, 2011 at 3:11 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:

 From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
 Behalf Of Jeremy Orlow
 Sent: Tuesday, March 15, 2011 3:08 PM

 Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310

 I'm not sure if this is a lot more valuable than just creating an index over 
 whatever index key you want plus the primary key, and then seeking to the 
 compound key of the last row in the previous page to resume scanning the next 
 page of records. No strong pushback, just not sure this is worth the extra 
 method.

The use-case here was  a paged UI that at the bottom allowed you to go
to any page. In this scenario you may not ever visit the page before
the one you want to display, and so you don't know which key to jump
to.

/ Jonas

Re: Indexed Database API

[Jeremy Orlow]

Filed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12310

On Fri, Mar 4, 2011 at 5:45 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking jo...@sicking.cc wrote:

 A few observations:

 1. It seems like a fairly rare use case to have to jump to item #100
 without first also observing item 1-99. When showing a paged view
 which lets the user to jump directly to, say, page 5 it can certainly
 happen, but the page could optimize for the case when the user first
 goes through page 1-4.
 2. Since it's not a common case, adding support for it just on
 cursors, rather than cursors and objectStores, seems enough. Would be
 as simple as adding a .advance (or similarly named function) which
 simply takes an integer. I don't see that we need to support jumping
 in a arbitrary direction since we don't allow continue() in an
 arbitrary direction.
 3. We do have a bit of a hole in our index-cursor API. While you can
 start the cursor at an arbitrary key, you can only start it at the
 first entry with that key in the case when there are duplicate keys.
 So if you iterate an index 10 records at a time, even if you never
 need to skip any entries, you can't always resume where you left off,
 even if you know the exact key+primaryKey for the record you want to
 resume at.


 I agree with all of this reasoning.


 4. While I agree that count() seems like a useful function, my concern
 is that people might think it's a cheap operation.


 This is my concern with your getAll function, btw.  :-)


 Getting the count
 for a full objectStore or index should be quick, but getting the count
 for a given key range (such as on a cursor) seems like it could be
 expensive. My b-tree knowledge isn't the best, but isn't there a risk
 that you have to linearly walk the full keyrange? Or does b-trees keep
 an exact count of record in each node? Even if linear walking is
 required, there might not be much we can do, and the best we can do is
 to document that this is a slow operation.


 I don't think we should limit our thinking to btrees, but it seems as
 though implementations could keep track of the number of children under a
 particular node, in which case it should be faster than linear.

 COUNT(*) is a very popular function in SQL (even with WHERE clauses).  It
 seems like there will be some cases where the implementor truly does need a
 count but not the data.  And given that at least some implementations should
 be able to optimize this, I think we should give them an API call.

 J

 On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Fri, Mar 4, 2011 at 1:38 PM, ben turner bent.mozi...@gmail.com
 wrote:
 
  Firefox does lazily deserialize cursor values, so the slowdown you're
  noticing is most likely due to us preserving the order of request
  callbacks by queuing every continue() call in line with the rest of
  the transaction. Jonas had proposed a faster, high performance cursor
  that did not respect this ordering, maybe that's all that you'd need.
 
  However, a few thoughts:
 
  1. How do you know Page 5 even exists? We haven't exposed a count()
  function yet...
  2. I think we should expose a count() function!
  3. Maybe we should expose a getAt(long index, enum direction);
  function on indexes and objectStores?
 
  A count function might make sense.
  But in this case, you could just jump forward to page 5 and see if you
 get
  an error or not.
  I'd lean towards just adding jumping forward to cursors for now though.
  If
  getting a single item at some position is popular, then we can always
 add
  it.
  Let's avoid adding prioritization of cursor.continue calls unless we
 have
  absolutely no other choice.
  J
 
  On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay olli.pet...@helsinki.fi
  wrote:
   On 03/02/2011 09:02 AM, Ben Dilts wrote:
  
   Why is there no mechanism for paging results, a la SQL's limit?
  If I
   want entries in positions 140-159 from an index, I have to call
   continue() on a cursor 139 times, which in turn unserializes 139
   objects
   from my store that I don't care about, which in FF4 is making a
 lookup
   in IndexedDB sometimes take many seconds for even a few records.
  
   Sounds like there is something to optimize in the implementation.
   Have you filed a bug
   https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
   component DOM ?
   If not, please do so and attach a *minimal* testcase.
  
  
   Thanks,
  
  
   -Olli
  
  
It
  
   makes no sense--am I just missing something in the spec?
  
  
   Ben Dilts
  
  
 
 
 

Indexed Database API

[Ben Dilts]

Why is there no mechanism for paging results, a la SQL's limit?  If I want
entries in positions 140-159 from an index, I have to call continue() on a
cursor 139 times, which in turn unserializes 139 objects from my store that
I don't care about, which in FF4 is making a lookup in IndexedDB sometimes
take many seconds for even a few records.  It makes no sense--am I just
missing something in the spec?


Ben Dilts

Re: Indexed Database API

[Jeremy Orlow]

On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts b...@lucidchart.com wrote:

 Why is there no mechanism for paging results, a la SQL's limit?  If I
 want entries in positions 140-159 from an index, I have to call continue()
 on a cursor 139 times, which in turn unserializes 139 objects from my store
 that I don't care about, which in FF4 is making a lookup in IndexedDB
 sometimes take many seconds for even a few records.  It makes no sense--am I
 just missing something in the spec?


Just use cursor.continue() with a key parameter to skip the cursor ahead to
where you care about.

J

Re: Indexed Database API

[Ben Dilts]

Jeremy,

Thanks for the reply!  However, my indices are not typically unique,
contiguous numbers.  For example, I have an index on an item's saved date,
as a MySQL-style date/time string.  These dates are not necessarily unique,
and are certainly not contiguous.  So if a user is currently viewing the
first 20 items in this object store, and would like to jump to page 5 (items
81-100), how would I go about that?  I don't know what key value is in the
81st position in the index.  In fact, the key value in position 81 may also
occupy positions 80 and 82--if I skip to that key value, I may end up in a
slightly wrong place.


Ben Dilts

On Fri, Mar 4, 2011 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts b...@lucidchart.com wrote:

 Why is there no mechanism for paging results, a la SQL's limit?  If I
 want entries in positions 140-159 from an index, I have to call continue()
 on a cursor 139 times, which in turn unserializes 139 objects from my store
 that I don't care about, which in FF4 is making a lookup in IndexedDB
 sometimes take many seconds for even a few records.  It makes no sense--am I
 just missing something in the spec?


 Just use cursor.continue() with a key parameter to skip the cursor ahead to
 where you care about.

 J

Re: Indexed Database API

[Jeremy Orlow]

On Fri, Mar 4, 2011 at 11:33 AM, Ben Dilts b...@lucidchart.com wrote:

 Jeremy,

 Thanks for the reply!  However, my indices are not typically unique,
 contiguous numbers.  For example, I have an index on an item's saved date,
 as a MySQL-style date/time string.  These dates are not necessarily unique,
 and are certainly not contiguous.  So if a user is currently viewing the
 first 20 items in this object store, and would like to jump to page 5 (items
 81-100), how would I go about that?  I don't know what key value is in the
 81st position in the index.  In fact, the key value in position 81 may also
 occupy positions 80 and 82--if I skip to that key value, I may end up in a
 slightly wrong place.


If you're jumping beyond what you've already looked at, then yeah...the
current API is probably not sufficient.

I wouldn't mind adding an option to openCursor to start the cursor some
number of items forward of the first element in the key range.  I also
wouldn't mind adding some sort of jumpForward method to IDBCursor.

J


 On Fri, Mar 4, 2011 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts b...@lucidchart.com wrote:

 Why is there no mechanism for paging results, a la SQL's limit?  If I
 want entries in positions 140-159 from an index, I have to call continue()
 on a cursor 139 times, which in turn unserializes 139 objects from my store
 that I don't care about, which in FF4 is making a lookup in IndexedDB
 sometimes take many seconds for even a few records.  It makes no sense--am I
 just missing something in the spec?


 Just use cursor.continue() with a key parameter to skip the cursor ahead
 to where you care about.

 J

Re: Indexed Database API

[Olli Pettay]

On 03/02/2011 09:02 AM, Ben Dilts wrote:

Why is there no mechanism for paging results, a la SQL's limit?  If I
want entries in positions 140-159 from an index, I have to call
continue() on a cursor 139 times, which in turn unserializes 139 objects
from my store that I don't care about, which in FF4 is making a lookup
in IndexedDB sometimes take many seconds for even a few records.


Sounds like there is something to optimize in the implementation.
Have you filed a bug 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core component DOM ?

If not, please do so and attach a *minimal* testcase.


Thanks,


-Olli


  It

makes no sense--am I just missing something in the spec?


Ben Dilts

Re: Indexed Database API

[ben turner]

Firefox does lazily deserialize cursor values, so the slowdown you're
noticing is most likely due to us preserving the order of request
callbacks by queuing every continue() call in line with the rest of
the transaction. Jonas had proposed a faster, high performance cursor
that did not respect this ordering, maybe that's all that you'd need.

However, a few thoughts:

1. How do you know Page 5 even exists? We haven't exposed a count()
function yet...
2. I think we should expose a count() function!
3. Maybe we should expose a getAt(long index, enum direction);
function on indexes and objectStores?

-Ben

On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
 On 03/02/2011 09:02 AM, Ben Dilts wrote:

 Why is there no mechanism for paging results, a la SQL's limit?  If I
 want entries in positions 140-159 from an index, I have to call
 continue() on a cursor 139 times, which in turn unserializes 139 objects
 from my store that I don't care about, which in FF4 is making a lookup
 in IndexedDB sometimes take many seconds for even a few records.

 Sounds like there is something to optimize in the implementation.
 Have you filed a bug https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
 component DOM ?
 If not, please do so and attach a *minimal* testcase.


 Thanks,


 -Olli


  It

 makes no sense--am I just missing something in the spec?


 Ben Dilts

Re: Indexed Database API

[Jeremy Orlow]

On Fri, Mar 4, 2011 at 1:38 PM, ben turner bent.mozi...@gmail.com wrote:

 Firefox does lazily deserialize cursor values, so the slowdown you're
 noticing is most likely due to us preserving the order of request
 callbacks by queuing every continue() call in line with the rest of
 the transaction. Jonas had proposed a faster, high performance cursor
 that did not respect this ordering, maybe that's all that you'd need.

 However, a few thoughts:

 1. How do you know Page 5 even exists? We haven't exposed a count()
 function yet...
 2. I think we should expose a count() function!
 3. Maybe we should expose a getAt(long index, enum direction);
 function on indexes and objectStores?


A count function might make sense.

But in this case, you could just jump forward to page 5 and see if you get
an error or not.

I'd lean towards just adding jumping forward to cursors for now though.  If
getting a single item at some position is popular, then we can always add
it.

Let's avoid adding prioritization of cursor.continue calls unless we have
absolutely no other choice.

J

On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay olli.pet...@helsinki.fi
 wrote:
  On 03/02/2011 09:02 AM, Ben Dilts wrote:
 
  Why is there no mechanism for paging results, a la SQL's limit?  If I
  want entries in positions 140-159 from an index, I have to call
  continue() on a cursor 139 times, which in turn unserializes 139 objects
  from my store that I don't care about, which in FF4 is making a lookup
  in IndexedDB sometimes take many seconds for even a few records.
 
  Sounds like there is something to optimize in the implementation.
  Have you filed a bug
 https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
  component DOM ?
  If not, please do so and attach a *minimal* testcase.
 
 
  Thanks,
 
 
  -Olli
 
 
   It
 
  makes no sense--am I just missing something in the spec?
 
 
  Ben Dilts
 
 

Re: Indexed Database API

[Jonas Sicking]

A few observations:

1. It seems like a fairly rare use case to have to jump to item #100
without first also observing item 1-99. When showing a paged view
which lets the user to jump directly to, say, page 5 it can certainly
happen, but the page could optimize for the case when the user first
goes through page 1-4.
2. Since it's not a common case, adding support for it just on
cursors, rather than cursors and objectStores, seems enough. Would be
as simple as adding a .advance (or similarly named function) which
simply takes an integer. I don't see that we need to support jumping
in a arbitrary direction since we don't allow continue() in an
arbitrary direction.
3. We do have a bit of a hole in our index-cursor API. While you can
start the cursor at an arbitrary key, you can only start it at the
first entry with that key in the case when there are duplicate keys.
So if you iterate an index 10 records at a time, even if you never
need to skip any entries, you can't always resume where you left off,
even if you know the exact key+primaryKey for the record you want to
resume at.
4. While I agree that count() seems like a useful function, my concern
is that people might think it's a cheap operation. Getting the count
for a full objectStore or index should be quick, but getting the count
for a given key range (such as on a cursor) seems like it could be
expensive. My b-tree knowledge isn't the best, but isn't there a risk
that you have to linearly walk the full keyrange? Or does b-trees keep
an exact count of record in each node? Even if linear walking is
required, there might not be much we can do, and the best we can do is
to document that this is a slow operation.

/ Jonas

On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow jor...@chromium.org wrote:
 On Fri, Mar 4, 2011 at 1:38 PM, ben turner bent.mozi...@gmail.com wrote:

 Firefox does lazily deserialize cursor values, so the slowdown you're
 noticing is most likely due to us preserving the order of request
 callbacks by queuing every continue() call in line with the rest of
 the transaction. Jonas had proposed a faster, high performance cursor
 that did not respect this ordering, maybe that's all that you'd need.

 However, a few thoughts:

 1. How do you know Page 5 even exists? We haven't exposed a count()
 function yet...
 2. I think we should expose a count() function!
 3. Maybe we should expose a getAt(long index, enum direction);
 function on indexes and objectStores?

 A count function might make sense.
 But in this case, you could just jump forward to page 5 and see if you get
 an error or not.
 I'd lean towards just adding jumping forward to cursors for now though.  If
 getting a single item at some position is popular, then we can always add
 it.
 Let's avoid adding prioritization of cursor.continue calls unless we have
 absolutely no other choice.
 J

 On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay olli.pet...@helsinki.fi
 wrote:
  On 03/02/2011 09:02 AM, Ben Dilts wrote:
 
  Why is there no mechanism for paging results, a la SQL's limit?  If I
  want entries in positions 140-159 from an index, I have to call
  continue() on a cursor 139 times, which in turn unserializes 139
  objects
  from my store that I don't care about, which in FF4 is making a lookup
  in IndexedDB sometimes take many seconds for even a few records.
 
  Sounds like there is something to optimize in the implementation.
  Have you filed a bug
  https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
  component DOM ?
  If not, please do so and attach a *minimal* testcase.
 
 
  Thanks,
 
 
  -Olli
 
 
   It
 
  makes no sense--am I just missing something in the spec?
 
 
  Ben Dilts
 
 

Re: Indexed Database API

[Jeremy Orlow]

On Fri, Mar 4, 2011 at 5:36 PM, Jonas Sicking jo...@sicking.cc wrote:

 A few observations:

 1. It seems like a fairly rare use case to have to jump to item #100
 without first also observing item 1-99. When showing a paged view
 which lets the user to jump directly to, say, page 5 it can certainly
 happen, but the page could optimize for the case when the user first
 goes through page 1-4.
 2. Since it's not a common case, adding support for it just on
 cursors, rather than cursors and objectStores, seems enough. Would be
 as simple as adding a .advance (or similarly named function) which
 simply takes an integer. I don't see that we need to support jumping
 in a arbitrary direction since we don't allow continue() in an
 arbitrary direction.
 3. We do have a bit of a hole in our index-cursor API. While you can
 start the cursor at an arbitrary key, you can only start it at the
 first entry with that key in the case when there are duplicate keys.
 So if you iterate an index 10 records at a time, even if you never
 need to skip any entries, you can't always resume where you left off,
 even if you know the exact key+primaryKey for the record you want to
 resume at.


I agree with all of this reasoning.


 4. While I agree that count() seems like a useful function, my concern
 is that people might think it's a cheap operation.


This is my concern with your getAll function, btw.  :-)


 Getting the count
 for a full objectStore or index should be quick, but getting the count
 for a given key range (such as on a cursor) seems like it could be
 expensive. My b-tree knowledge isn't the best, but isn't there a risk
 that you have to linearly walk the full keyrange? Or does b-trees keep
 an exact count of record in each node? Even if linear walking is
 required, there might not be much we can do, and the best we can do is
 to document that this is a slow operation.


I don't think we should limit our thinking to btrees, but it seems as though
implementations could keep track of the number of children under a
particular node, in which case it should be faster than linear.

COUNT(*) is a very popular function in SQL (even with WHERE clauses).  It
seems like there will be some cases where the implementor truly does need a
count but not the data.  And given that at least some implementations should
be able to optimize this, I think we should give them an API call.

J

On Fri, Mar 4, 2011 at 2:32 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Fri, Mar 4, 2011 at 1:38 PM, ben turner bent.mozi...@gmail.com
 wrote:
 
  Firefox does lazily deserialize cursor values, so the slowdown you're
  noticing is most likely due to us preserving the order of request
  callbacks by queuing every continue() call in line with the rest of
  the transaction. Jonas had proposed a faster, high performance cursor
  that did not respect this ordering, maybe that's all that you'd need.
 
  However, a few thoughts:
 
  1. How do you know Page 5 even exists? We haven't exposed a count()
  function yet...
  2. I think we should expose a count() function!
  3. Maybe we should expose a getAt(long index, enum direction);
  function on indexes and objectStores?
 
  A count function might make sense.
  But in this case, you could just jump forward to page 5 and see if you
 get
  an error or not.
  I'd lean towards just adding jumping forward to cursors for now though.
  If
  getting a single item at some position is popular, then we can always add
  it.
  Let's avoid adding prioritization of cursor.continue calls unless we have
  absolutely no other choice.
  J
 
  On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay olli.pet...@helsinki.fi
  wrote:
   On 03/02/2011 09:02 AM, Ben Dilts wrote:
  
   Why is there no mechanism for paging results, a la SQL's limit?  If
 I
   want entries in positions 140-159 from an index, I have to call
   continue() on a cursor 139 times, which in turn unserializes 139
   objects
   from my store that I don't care about, which in FF4 is making a
 lookup
   in IndexedDB sometimes take many seconds for even a few records.
  
   Sounds like there is something to optimize in the implementation.
   Have you filed a bug
   https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
   component DOM ?
   If not, please do so and attach a *minimal* testcase.
  
  
   Thanks,
  
  
   -Olli
  
  
It
  
   makes no sense--am I just missing something in the spec?
  
  
   Ben Dilts
  
  
 
 
 

RE: CfC: to publish new WD of Indexed Database API; deadline August 17

[Pablo Castro]

We support this as well.

-pablo


-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Jonas Sicking
Sent: Tuesday, August 10, 2010 8:06 AM
To: Jeremy Orlow
Cc: art.bars...@nokia.com; public-webapps
Subject: Re: CfC: to publish new WD of Indexed Database API; deadline August 17

I support this.

On Tue, Aug 10, 2010 at 4:38 AM, Jeremy Orlow jor...@google.com wrote:
 On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.com
 wrote:

 All - the Editors of the Indexed Database API would like to publish a new
 Working Draft:

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If you have any comments or concerns about this proposal, please send them
 to public-webapps by August 10 at the latest.

 I assume you mean the 17th?

 As with all of our CfCs, positive response is preferred and encouraged and
 silence will be assumed to be assent.

 We support.

CfC: to publish new WD of Indexed Database API; deadline August 17

[Arthur Barstow]

All - the Editors of the Indexed Database API would like to publish a 
new Working Draft:


  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

If you have any comments or concerns about this proposal, please send 
them to public-webapps by August 10 at the latest.


As with all of our CfCs, positive response is preferred and encouraged 
and silence will be assumed to be assent.


-Art Barstow

Re: CfC: to publish new WD of Indexed Database API; deadline August 17

[Jeremy Orlow]

On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.comwrote:

 All - the Editors of the Indexed Database API would like to publish a new
 Working Draft:

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If you have any comments or concerns about this proposal, please send them
 to public-webapps by August 10 at the latest.


I assume you mean the 17th?

As with all of our CfCs, positive response is preferred and encouraged and
 silence will be assumed to be assent.


We support.

Re: CfC: to publish new WD of Indexed Database API; deadline August 17

[Arthur Barstow]

Yes, the deadline for comments is August 17!

On 8/10/10 7:38 AM, ext Jeremy Orlow wrote:
On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow 
art.bars...@nokia.com mailto:art.bars...@nokia.com wrote:


All - the Editors of the Indexed Database API would like to
publish a new Working Draft:

http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

If you have any comments or concerns about this proposal, please
send them to public-webapps by August 10 at the latest.


I assume you mean the 17th?

As with all of our CfCs, positive response is preferred and
encouraged and silence will be assumed to be assent.


We support.

Re: CfC: to publish new WD of Indexed Database API; deadline August 17

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Any chance #10304 could be resolved prior to the publishing? Seems
like it would be nice to get a change to the core store API sooner
rather than later. Either way, I am +1 for publishing though.
Thanks,
Kris

On 8/10/2010 5:04 AM, Arthur Barstow wrote:
 All - the Editors of the Indexed Database API would like to publish
 a new Working Draft:

   http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If you have any comments or concerns about this proposal, please
 send them to public-webapps by August 10 at the latest.

 As with all of our CfCs, positive response is preferred and
 encouraged and silence will be assumed to be assent.

 -Art Barstow



- -- 
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/
 
iEYEARECAAYFAkxhVu4ACgkQ9VpNnHc4zAyHygCfU1nLMK8WLnG1FETtaOtbpLDn
nxgAnAxoTdIwTx22NCJPrE5l9jeC4PJS
=8p1i
-END PGP SIGNATURE-

Re: CfC: to publish new WD of Indexed Database API; deadline August 17

[Jonas Sicking]

I support this.

On Tue, Aug 10, 2010 at 4:38 AM, Jeremy Orlow jor...@google.com wrote:
 On Tue, Aug 10, 2010 at 12:04 PM, Arthur Barstow art.bars...@nokia.com
 wrote:

 All - the Editors of the Indexed Database API would like to publish a new
 Working Draft:

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

 If you have any comments or concerns about this proposal, please send them
 to public-webapps by August 10 at the latest.

 I assume you mean the 17th?

 As with all of our CfCs, positive response is preferred and encouraged and
 silence will be assumed to be assent.

 We support.

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

[timeless]

Whomever adds delete/continue back to the spec needs to inline into
the spec an explanation of why it's ok per ES5.

Most (all) of us grew up pre ES5 and *believe* that they're truly
reserved keywords and that what you're doing is invalid.

So without inlining the explanation into the spec, you're asking for
people to think you're crazy.

Personally, i think trying to mark something as locally unreserved is
crazy, since you're fighting the web's collective knowledge.

http://javascript.about.com/od/reference/g/rdelete.htm
Definition: The delete statement deletes an object that was created
using the new statement. Delete is a reserved word and cannot be used
for anything other than deleting an object.

Note that it seems clear that people here do not care about the web's
collective knowledge, so I'm not asking you to stop.

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 6/15/2010 12:36 PM, Jonas Sicking wrote:
 On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
 pablo.cas...@microsoft.com wrote:
 We developed a similar trick where we can indicate in the IDL
 that different names are used for scripted languages and for
 compiled languages.

 So all in all I believe this problem can be overcome. I
 prefer to focus on making the JS API be the best it can be,
 and let other languages take a back seat. As long as it's
 solvable without too much of an issue (such as large
 performance penalties) in other languages.

 I agree we can sort this out and certainly limitations on the
 implementation language shouldn't surface here. The issue is more
 whether folks care about a C++ binding (or some other language
 with a similar issue) where we'll have to have a different name
 for this method.

 Even though I've been bringing this up I'm ok with keeping
 delete(), I just want to make sure we understand all the
 implications that come with that.

 I'm also ok with keeping delete(), as well as continue(). This
 despite realizing that it might mean that different C++
 implementations might map these names differently into C++.

 / Jonas



It sounds like returning to delete() for deleting records from a store
is agreeable. Can the spec be updated or are we still sticking with
remove()?

- -- 
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/
 
iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK
6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb
=lG0c
-END PGP SIGNATURE-

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

[Jonas Sicking]

There seems to be agreement that delete() is acceptable. Could you file a bug?

/ Jonas

On Monday, July 5, 2010, Kris Zyp k...@sitepen.com wrote:







 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 6/15/2010 12:36 PM, Jonas Sicking wrote:
 On Mon, Jun 14, 2010 at 11:20
 PM, Pablo Castro
 pablo.cas...@microsoft.com pablo.cas...@microsoft.com wrote:
 We developed a similar trick where we can indicate
 in the IDL
 that different names are used for scripted languages
 and for
 compiled languages.

 So all in all I believe this problem can be
 overcome. I
 prefer to focus on making the JS API be the best it
 can be,
 and let other languages take a back seat. As long as
 it's
 solvable without too much of an issue (such as large
 performance penalties) in other languages.

 I agree we can sort this out and certainly limitations on the
 implementation language shouldn't surface here. The issue is
 more
 whether folks care about a C++ binding (or some other
 language
 with a similar issue) where we'll have to have a different
 name
 for this method.

 Even though I've been bringing this up I'm ok with keeping
 delete(), I just want to make sure we understand all the
 implications that come with that.

 I'm also ok with keeping delete(), as well as continue(). This
 despite realizing that it might mean that different C++
 implementations might map these names differently into C++.

 / Jonas



 It sounds like returning to delete() for deleting records from a store
 is agreeable. Can the spec be updated or are we still sticking with
 remove()?

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


 iEYEARECAAYFAkwyBO4ACgkQ9VpNnHc4zAyx4wCdHvOjnGlUyAj4Jbf0bZAlQqmK

 6hEAoMApBEMfgaPaa8R/U9kNGG25JoNb

 =lG0c

 -END PGP SIGNATURE-

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

[Pablo Castro]

From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Friday, June 11, 2010 3:20 PM

   So there is a real likelyhood of a browser implementation that 
   will predate it's associated JS engine's upgrade to ES5? 
   Feeling a concern isn't really much of technical argument on 
   it's own, and designing for outdated technology is a poor approach.
  I don't think there is, just wanted to avoid imposing it. If you 
  think it's really important then let's change it back to delete 
  assuming other folks are good with it.

  I had the same concerns Pablo did, but I don't feel strongly 
  either way.

Besides the maneuvering we'll have to do on the C++ side of things to avoid 
clashes with language keywords, the question is whether we expect plugins and 
such to add support for IndexedDB in existing browsers that don't do ES5. For 
example:
http://code.google.com/p/firebreath/wiki/FireBreathUsers


 Before we close on this, let me validate one more thing independently 
 of the JS version. Are we going to have trouble when trying to expose 
 these interfaces in C++? Not sure about other compilers and IDL 
 processing tools, but I'm playing around with Visual Studio 2010 and 
 while the COM IDL compiler will take delete as an interface member, 
 my C++ compiler really doesn't like it. As far as I know there is no 
 standard syntax to indicate that a symbol wasn't meant to be a 
 keyword in C++, so having delete (or other C++ keywords for that 
 matter) would be problematic. Am I missing something?

 Good point.  Does anyone have a strong opinion on how much we should 
 care about reserved word conflicts in language other than JavaScript?  
 it seems like a slippery slope.
 As an example, IDBDatabase.description is actually used by the 
 ObjectiveC base object class and so this caused some problems 
 initially.  We worked around it by having the ObjectiveC bindings 
 generator add a suffix whenever an attribute named description is 
 hit.  (Something similar was done for hash and id in other APIs.) 
 To be honest, I hadn't even considered bringing this up and asking for 
 it to be changed, but if we're going to avoid delete because it's a 
 reserved word in JavaScript (pre v5) and/or because it's a reserved 
 word in C++, perhaps we should consider changing description as well?

 We've had to do this a few times in the past already. One example was 
 Window.postMessage where we couldn't use the name PostMessage in C++ 
 because it was a predefined macro on some platform (windows iirc, not to 
 point fingers ;) ).

:)

 We developed a similar trick where we can indicate in the IDL that different 
 names are used for scripted languages and for compiled languages.

 So all in all I believe this problem can be overcome. I prefer to focus on 
 making the JS API be the best it can be, and let other languages take a back 
 seat. As long as it's solvable without too much of an issue (such as large 
 performance penalties) in other languages.

I agree we can sort this out and certainly limitations on the implementation 
language shouldn't surface here. The issue is more whether folks care about a 
C++ binding (or some other language with a similar issue) where we'll have to 
have a different name for this method.

Even though I've been bringing this up I'm ok with keeping delete(), I just 
want to make sure we understand all the implications that come with that.

-pablo
 

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

[Jonas Sicking]

On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
 We developed a similar trick where we can indicate in the IDL that 
 different names are used for scripted languages and for compiled languages.

 So all in all I believe this problem can be overcome. I prefer to focus on 
 making the JS API be the best it can be, and let other languages take a 
 back seat. As long as it's solvable without too much of an issue (such as 
 large performance penalties) in other languages.

 I agree we can sort this out and certainly limitations on the implementation 
 language shouldn't surface here. The issue is more whether folks care about a 
 C++ binding (or some other language with a similar issue) where we'll have to 
 have a different name for this method.

 Even though I've been bringing this up I'm ok with keeping delete(), I just 
 want to make sure we understand all the implications that come with that.

I'm also ok with keeping delete(), as well as continue(). This despite
realizing that it might mean that different C++ implementations might
map these names differently into C++.

/ Jonas

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

[Jeremy Orlow]

On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
 pablo.cas...@microsoft.com wrote:
  We developed a similar trick where we can indicate in the IDL that
 different names are used for scripted languages and for compiled languages.
 
  So all in all I believe this problem can be overcome. I prefer to focus
 on making the JS API be the best it can be, and let other languages take a
 back seat. As long as it's solvable without too much of an issue (such as
 large performance penalties) in other languages.
 
  I agree we can sort this out and certainly limitations on the
 implementation language shouldn't surface here. The issue is more whether
 folks care about a C++ binding (or some other language with a similar issue)
 where we'll have to have a different name for this method.
 
  Even though I've been bringing this up I'm ok with keeping delete(), I
 just want to make sure we understand all the implications that come with
 that.

 I'm also ok with keeping delete(), as well as continue(). This despite
 realizing that it might mean that different C++ implementations might
 map these names differently into C++.


Isn't continue a _JS_ reserved word though?

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 6/15/2010 12:40 PM, Jeremy Orlow wrote:
 On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro
 pablo.cas...@microsoft.com mailto:pablo.cas...@microsoft.com
 wrote:
  We developed a similar trick where we can indicate in the
 IDL that different names are used for scripted languages and for
 compiled languages.
 
  So all in all I believe this problem can be overcome. I
 prefer to focus on making the JS API be the best it can be, and
 let other languages take a back seat. As long as it's solvable
 without too much of an issue (such as large performance
 penalties) in other languages.
 
  I agree we can sort this out and certainly limitations on the
 implementation language shouldn't surface here. The issue is
 more whether folks care about a C++ binding (or some other
 language with a similar issue) where we'll have to have a
 different name for this method.
 
  Even though I've been bringing this up I'm ok with keeping
 delete(), I just want to make sure we understand all the
 implications that come with that.

 I'm also ok with keeping delete(), as well as continue(). This
 despite
 realizing that it might mean that different C++ implementations
 might
 map these names differently into C++.


 Isn't continue a _JS_ reserved word though?

Not as a property on the primary expected target language, EcmaScript 5.

- -- 
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/
 
iEYEARECAAYFAkwXy9YACgkQ9VpNnHc4zAwlAwCguToFcLXY5FgGyL/7acDr4LKR
LF0Anj96a/A6ChOeXCMHzlTv8A1xnhZy
=TKKA
-END PGP SIGNATURE-

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

[Marcus Bulach]

Hi,

(brief background before jumping out of the blue: I'm working with
Andrei and Jeremy with the IDB implementation..)

I'd like to mention the IDBCursor::continue is also problematic, as
afaict continue is a reserved keyword in JS?
oh, delete seems to be reserved as well:
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Reserved_Words

Not sure what to suggest though, perhaps move() ? We can't have
next(), since the cursor is opened with a direction..

thoughts?

Thanks,
Marcus


On Tue, Jun 15, 2010 at 7:20 AM, Pablo Castro
pablo.cas...@microsoft.com wrote:

 From: Jonas Sicking [mailto:jo...@sicking.cc]
 Sent: Friday, June 11, 2010 3:20 PM

   So there is a real likelyhood of a browser implementation that
   will predate it's associated JS engine's upgrade to ES5?
   Feeling a concern isn't really much of technical argument on
   it's own, and designing for outdated technology is a poor approach.
  I don't think there is, just wanted to avoid imposing it. If you
  think it's really important then let's change it back to delete
  assuming other folks are good with it.

  I had the same concerns Pablo did, but I don't feel strongly
  either way.

 Besides the maneuvering we'll have to do on the C++ side of things to avoid 
 clashes with language keywords, the question is whether we expect plugins and 
 such to add support for IndexedDB in existing browsers that don't do ES5. For 
 example:
 http://code.google.com/p/firebreath/wiki/FireBreathUsers


 Before we close on this, let me validate one more thing independently
 of the JS version. Are we going to have trouble when trying to expose
 these interfaces in C++? Not sure about other compilers and IDL
 processing tools, but I'm playing around with Visual Studio 2010 and
 while the COM IDL compiler will take delete as an interface member,
 my C++ compiler really doesn't like it. As far as I know there is no
 standard syntax to indicate that a symbol wasn't meant to be a
 keyword in C++, so having delete (or other C++ keywords for that
 matter) would be problematic. Am I missing something?

 Good point.  Does anyone have a strong opinion on how much we should
 care about reserved word conflicts in language other than JavaScript?
 it seems like a slippery slope.
 As an example, IDBDatabase.description is actually used by the
 ObjectiveC base object class and so this caused some problems
 initially.  We worked around it by having the ObjectiveC bindings
 generator add a suffix whenever an attribute named description is
 hit.  (Something similar was done for hash and id in other APIs.)
 To be honest, I hadn't even considered bringing this up and asking for
 it to be changed, but if we're going to avoid delete because it's a
 reserved word in JavaScript (pre v5) and/or because it's a reserved
 word in C++, perhaps we should consider changing description as well?

 We've had to do this a few times in the past already. One example was 
 Window.postMessage where we couldn't use the name PostMessage in C++ 
 because it was a predefined macro on some platform (windows iirc, not to 
 point fingers ;) ).

 :)

 We developed a similar trick where we can indicate in the IDL that 
 different names are used for scripted languages and for compiled languages.

 So all in all I believe this problem can be overcome. I prefer to focus on 
 making the JS API be the best it can be, and let other languages take a 
 back seat. As long as it's solvable without too much of an issue (such as 
 large performance penalties) in other languages.

 I agree we can sort this out and certainly limitations on the implementation 
 language shouldn't surface here. The issue is more whether folks care about a 
 C++ binding (or some other language with a similar issue) where we'll have to 
 have a different name for this method.

 Even though I've been bringing this up I'm ok with keeping delete(), I just 
 want to make sure we understand all the implications that come with that..

 -pablo

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

[Pablo Castro]

From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Friday, June 11, 2010 3:20 AM
Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
February 2

On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com 
wrote:


From: Kris Zyp [mailto:k...@sitepen.com]
Sent: Thursday, June 10, 2010 4:38 PM
Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
February 2

  So there is a real likelyhood of a browser implementation that will
  predate it's associated JS engine's upgrade to ES5? Feeling a
  concern isn't really much of technical argument on it's own, and
  designing for outdated technology is a poor approach.
 I don't think there is, just wanted to avoid imposing it. If you think it's 
 really important then let's change it back to delete assuming other folks 
 are good with it.

 I had the same concerns Pablo did, but I don't feel strongly either way.

Before we close on this, let me validate one more thing independently of the JS 
version. Are we going to have trouble when trying to expose these interfaces in 
C++? Not sure about other compilers and IDL processing tools, but I'm playing 
around with Visual Studio 2010 and while the COM IDL compiler will take 
delete as an interface member, my C++ compiler really doesn't like it. As far 
as I know there is no standard syntax to indicate that a symbol wasn't meant to 
be a keyword in C++, so having delete (or other C++ keywords for that matter) 
would be problematic. Am I missing something?

-pablo

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

[Jeremy Orlow]

On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro pablo.cas...@microsoft.comwrote:


 From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
 Orlow
 Sent: Friday, June 11, 2010 3:20 AM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline
 February 2

 On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com
 wrote:


 From: Kris Zyp [mailto:k...@sitepen.com]
 Sent: Thursday, June 10, 2010 4:38 PM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline
 February 2

   So there is a real likelyhood of a browser implementation that will
   predate it's associated JS engine's upgrade to ES5? Feeling a
   concern isn't really much of technical argument on it's own, and
   designing for outdated technology is a poor approach.
  I don't think there is, just wanted to avoid imposing it. If you think
 it's really important then let's change it back to delete assuming other
 folks are good with it.

  I had the same concerns Pablo did, but I don't feel strongly either way.

 Before we close on this, let me validate one more thing independently of
 the JS version. Are we going to have trouble when trying to expose these
 interfaces in C++? Not sure about other compilers and IDL processing tools,
 but I'm playing around with Visual Studio 2010 and while the COM IDL
 compiler will take delete as an interface member, my C++ compiler really
 doesn't like it. As far as I know there is no standard syntax to indicate
 that a symbol wasn't meant to be a keyword in C++, so having delete (or
 other C++ keywords for that matter) would be problematic. Am I missing
 something?


Good point.  Does anyone have a strong opinion on how much we should care
about reserved word conflicts in language other than JavaScript?  it seems
like a slippery slope.

As an example, IDBDatabase.description is actually used by the ObjectiveC
base object class and so this caused some problems initially.  We worked
around it by having the ObjectiveC bindings generator add a suffix whenever
an attribute named description is hit.  (Something similar was done for
hash and id in other APIs.)

To be honest, I hadn't even considered bringing this up and asking for it to
be changed, but if we're going to avoid delete because it's a reserved word
in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps
we should consider changing description as well?

J

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

[Jonas Sicking]

On Thu, Jun 10, 2010 at 5:54 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:


 From: Kris Zyp [mailto:k...@sitepen.com]
 Sent: Thursday, June 10, 2010 4:38 PM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
 February 2

 On 6/10/2010 4:15 PM, Pablo Castro wrote:
 
  From: public-webapps-requ...@w3.org
  [mailto:public-webapps-requ...@w3.org] On Behalf Of Kris Zyp
  Sent: Thursday, June 10, 2010 9:49 AM Subject: Re: Seeking
  pre-LCWD comments for Indexed Database API; deadline February
  2
 
  I see that in the trunk version of the spec [1] that delete()
  was changed to remove(). I thought we had established that
  there is no reason to make this change. Is anyone seriously
  expecting to have an implementation prior to or without ES5's
  contextually unreserved keywords? I would greatly prefer
  delete(), as it is much more consistent with standard DB and
  REST terminology.
 
  My concern is that it seems like taking an unnecessary risk. I
  understand the familiarity aspect (and I like delete() better as
  well), but to me that's not a strong enough reason to use it and
  potentially cause trouble in some browser.
 
 So there is a real likelyhood of a browser implementation that will
 predate it's associated JS engine's upgrade to ES5? Feeling a
 concern isn't really much of technical argument on it's own, and
 designing for outdated technology is a poor approach.

 I don't think there is, just wanted to avoid imposing it. If you think it's 
 really important then let's change it back to delete assuming other folks are 
 good with it.

I just checked with our JS team and we'll implement enough of ES5 in
Firefox 4 that this won't be a problem for us.

/ Jonas

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

[Jonas Sicking]

On Fri, Jun 11, 2010 at 2:05 PM, Jeremy Orlow jor...@chromium.org wrote:
 On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro pablo.cas...@microsoft.com
 wrote:

 From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy
 Orlow
 Sent: Friday, June 11, 2010 3:20 AM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline
 February 2

 On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro pablo.cas...@microsoft.com
 wrote:


 From: Kris Zyp [mailto:k...@sitepen.com]
 Sent: Thursday, June 10, 2010 4:38 PM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline
 February 2

   So there is a real likelyhood of a browser implementation that will
   predate it's associated JS engine's upgrade to ES5? Feeling a
   concern isn't really much of technical argument on it's own, and
   designing for outdated technology is a poor approach.
  I don't think there is, just wanted to avoid imposing it. If you think
  it's really important then let's change it back to delete assuming other
  folks are good with it.

  I had the same concerns Pablo did, but I don't feel strongly either
  way.

 Before we close on this, let me validate one more thing independently of
 the JS version. Are we going to have trouble when trying to expose these
 interfaces in C++? Not sure about other compilers and IDL processing tools,
 but I'm playing around with Visual Studio 2010 and while the COM IDL
 compiler will take delete as an interface member, my C++ compiler really
 doesn't like it. As far as I know there is no standard syntax to indicate
 that a symbol wasn't meant to be a keyword in C++, so having delete (or
 other C++ keywords for that matter) would be problematic. Am I missing
 something?

 Good point.  Does anyone have a strong opinion on how much we should care
 about reserved word conflicts in language other than JavaScript?  it seems
 like a slippery slope.
 As an example, IDBDatabase.description is actually used by the ObjectiveC
 base object class and so this caused some problems initially.  We worked
 around it by having the ObjectiveC bindings generator add a suffix whenever
 an attribute named description is hit.  (Something similar was done for
 hash and id in other APIs.)
 To be honest, I hadn't even considered bringing this up and asking for it to
 be changed, but if we're going to avoid delete because it's a reserved word
 in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps
 we should consider changing description as well?

We've had to do this a few times in the past already. One example was
Window.postMessage where we couldn't use the name PostMessage in C++
because it was a predefined macro on some platform (windows iirc, not
to point fingers ;) ).

We developed a similar trick where we can indicate in the IDL that
different names are used for scripted languages and for compiled
languages.

So all in all I believe this problem can be overcome. I prefer to
focus on making the JS API be the best it can be, and let other
languages take a back seat. As long as it's solvable without too much
of an issue (such as large performance penalties) in other languages.

/ Jonas

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 2/2/2010 12:48 PM, Kris Zyp wrote:


 On 2/1/2010 8:17 PM, Pablo Castro wrote:
 [snip]



 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.



 You can't use member access syntax in IE8 and Safari 4 because
 they only implement EcmaScript3. But obviously, these aren't the
 target versions, the future versions would be the target of this
 spec. ES5 specifically contextually unreserves keywords, so
 obj.delete(id) is perfectly valid syntax for all target browser
 versions. ES5 predates Indexed DB API, so it doesn't make any sense
 to design around an outdated EcmaScript behavior (also it is still
 perfectly possible to set/call the delete property in ES3, you do
 so with object[delete](id)).


I see that in the trunk version of the spec [1] that delete() was
changed to remove(). I thought we had established that there is no
reason to make this change. Is anyone seriously expecting to have an
implementation prior to or without ES5's contextually unreserved
keywords? I would greatly prefer delete(), as it is much more
consistent with standard DB and REST terminology.

[1]
http://dvcs.w3.org/hg/IndexedDB/raw-file/d697d377f9ac/Overview.html#object-store-sync
- -- 
Thanks,
Kris

- -- 
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/
 
iEYEARECAAYFAkwRF2EACgkQ9VpNnHc4zAyFgwCeIhWGFQFXCrGdhCqSg43YLEur
mRcAn0hPK/EvQT17Oeg1EfT2VHp9goNF
=UO8O
-END PGP SIGNATURE-

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

[Pablo Castro]

 From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] 
 On Behalf Of Kris Zyp
 Sent: Thursday, June 10, 2010 9:49 AM
 Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
 February 2

 I see that in the trunk version of the spec [1] that delete() was
 changed to remove(). I thought we had established that there is no
 reason to make this change. Is anyone seriously expecting to have an
 implementation prior to or without ES5's contextually unreserved
 keywords? I would greatly prefer delete(), as it is much more
 consistent with standard DB and REST terminology.

My concern is that it seems like taking an unnecessary risk. I understand the 
familiarity aspect (and I like delete() better as well), but to me that's not a 
strong enough reason to use it and potentially cause trouble in some browser.

-pablo

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 6/10/2010 4:15 PM, Pablo Castro wrote:

 From: public-webapps-requ...@w3.org
 [mailto:public-webapps-requ...@w3.org] On Behalf Of Kris Zyp
 Sent: Thursday, June 10, 2010 9:49 AM Subject: Re: Seeking
 pre-LCWD comments for Indexed Database API; deadline February
 2

 I see that in the trunk version of the spec [1] that delete()
 was changed to remove(). I thought we had established that
 there is no reason to make this change. Is anyone seriously
 expecting to have an implementation prior to or without ES5's
 contextually unreserved keywords? I would greatly prefer
 delete(), as it is much more consistent with standard DB and
 REST terminology.

 My concern is that it seems like taking an unnecessary risk. I
 understand the familiarity aspect (and I like delete() better as
 well), but to me that's not a strong enough reason to use it and
 potentially cause trouble in some browser.

So there is a real likelyhood of a browser implementation that will
predate it's associated JS engine's upgrade to ES5? Feeling a
concern isn't really much of technical argument on it's own, and
designing for outdated technology is a poor approach.

- -- 
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/
 
iEYEARECAAYFAkwRd04ACgkQ9VpNnHc4zAwyegCfQlUO66XszuZeZtFVNrfBjV56
eRIAoLDjGDTdRzvIeLtfRHFnDhopFKGv
=ZhrJ
-END PGP SIGNATURE-

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

[Pablo Castro]

From: Kris Zyp [mailto:k...@sitepen.com] 
Sent: Thursday, June 10, 2010 4:38 PM
Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
February 2

 On 6/10/2010 4:15 PM, Pablo Castro wrote:
 
  From: public-webapps-requ...@w3.org
  [mailto:public-webapps-requ...@w3.org] On Behalf Of Kris Zyp
  Sent: Thursday, June 10, 2010 9:49 AM Subject: Re: Seeking
  pre-LCWD comments for Indexed Database API; deadline February
  2
 
  I see that in the trunk version of the spec [1] that delete()
  was changed to remove(). I thought we had established that
  there is no reason to make this change. Is anyone seriously
  expecting to have an implementation prior to or without ES5's
  contextually unreserved keywords? I would greatly prefer
  delete(), as it is much more consistent with standard DB and
  REST terminology.
 
  My concern is that it seems like taking an unnecessary risk. I
  understand the familiarity aspect (and I like delete() better as
  well), but to me that's not a strong enough reason to use it and
  potentially cause trouble in some browser.
 
 So there is a real likelyhood of a browser implementation that will
 predate it's associated JS engine's upgrade to ES5? Feeling a
 concern isn't really much of technical argument on it's own, and
 designing for outdated technology is a poor approach.

I don't think there is, just wanted to avoid imposing it. If you think it's 
really important then let's change it back to delete assuming other folks are 
good with it.

-pablo

RE: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Pablo Castro]

On Fri, Mar 12, 2010 at 7:26 AM, Jeremy Orlow wrote:

On Fri, Mar 12, 2010 at 3:23 PM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Mar 12, 2010 at 3:04 PM, Kris Zyp k...@sitepen.com wrote:


 I believe computer science has clearly
 observed the fragility of passing callbacks to the initial function
 since it conflates the concerns of the operation with the asynchronous
 notifications and consequently greatly complicates composability.

 I don't understand this sentence.  I'm pretty sure that you can wrap any 
 callback based API in JavaScript with a promised, differed, etc based API.  
 As  Nikunj mentioned earlier, we're more concerned about creating a small 
 API surface area and sticking with well understood API designs rather than 
  eliminating the need for libraries that wrap IndexedDB.
 
Trying to digest this thread, I think we've sort of gone full-circle with the 
whole promises thing. When looking at the code with the chained then pattern 
I just love the result, but it seems that we can't get all the way there (and 
nesting instead of chaining stuff kind of lacks the magic). My take is that 
either we get the really nice pattern by going all the way or we create a more 
traditional callback/events-based API and then we build promises on top. Things 
seem to indicate that frameworks are still cooking on promises, so it may be 
safe to stay with callbacks/events and just build libraries on top (I would 
have loved to have this be the thing that saved us from needing a library 
always...but it seems we'll fall just a bit short).

As for callbacks versus events, while now I'm starting to get used to the 
events hooked up to the result object after the call, the callbacks may be a 
more natural mechanism for this particular usage. I'm not sure why this is 
fundamentally broken...would love to see examples or reference. If that's the 
case, then events are the obvious choice.

Thanks
-pablo

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Shawn Wilsher]

On 3/5/2010 4:54 AM, Jeremy Orlow wrote:

For what it's worth, regardless of the answers to the above questions, I
think we should switch to a callback based model.  It's great to use
events when natural to do so, but this is a very unnatural use.  It
provides artificial limitations (only one request in flight at a time,
per request object).  It's ugly and confusing syntax wise (hard to keep
track of which request object is associated with which request method,
requires multiple statements to do each request, requires the handlers
to be placed prior to the actual call...which is why the async example
in http://www.w3.org/TR/IndexedDB/#introduction is so difficult to read,
etc).  And there really isn't any precedent (that I'm aware of) for
using events like this.  And the web developers I've spoken to have all
been confused by the async API.
For what it is worth, all the web developers we've talked to have pushed 
for an event based API, which is why we've been pushing for it.  This 
happened with the file reader API as I understand it (Jonas or Arun 
would be able to say more).


Note that we didn't show them this exact API.

Cheers,

Shawn



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 7:44 PM, Nikunj Mehta nik...@o-micron.com wrote:


 On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote:

  On 3/4/2010 11:46 AM, Nikunj Mehta wrote:
 
   On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
  
  
   On 3/4/2010 11:08 AM, Aaron Boodman wrote:
   [snip]
  
   * There is nothing preventing JS authors from implementing a
   promise-style API on top of IndexedDB, if that is what they
   want to do.
  
   Yes, you can always make an API harder to use so that JS authors
   have more they can do with it ;).
  
   You will agree that we don't want to wait for one style of
   promises to win out over others before IndexedDB can be made
   available to programmers. Till the soil and let a thousand flowers
   bloom.

 The IndexedDB spec isn't and can't just sit back and not define the
 asynchronous interface. Like it or not, IndexedDB has defined a
 promise-like entity with the |DBRequest| interface. Why is inventing a
 new (and somewhat ugly) flower better than designing based on the many
 flowers that have already bloomed?


 I meant to say that the IndexedDB spec should be updated to use a model
 that supports promises. If the current one is not adequate then, by all
 means, let's make it. However, we don't need a full-fledged promises in
 IndexedDB. I hope you agree this time.


FWIW, I agree.


To get promises to work with the current event based implementation, it'd be
somewhat complex.  Since there can only be one request in flight at a time,
the implementation would need to know which requests would be using the same
request object and implement a queue for each one (or implement a global
queue if that's not practical).  Whenever an onsuccess or onerror callback
is called, it'd need to check to see if there are any queued up requests
(and would fire them if so).  This seems complex and ugly, but certainly
possible.

If the interface were callback based, a library would simply create a
promise object, create an onsuccess closure, create an onerror closure, and
pass those into the callbacks.  When the callbacks are called, they'd have a
reference to the promise (since they were created with access to the promise
object due to their scope) and could easily fulfill the promise.

Of course, I'm probably re-inventing the wheel here; there are enough other
callback based APIs that I assume this is a solved (and optimized problem).
 Are there any other APIs that use the request event based style like how
IndexedDB is currently specced?  If so, can anyone share any experience with
the list?  If not, does anyone foresee major problems and/or have an opinion
on how easy it'll be to adapt promises to the API?


For what it's worth, regardless of the answers to the above questions, I
think we should switch to a callback based model.  It's great to use events
when natural to do so, but this is a very unnatural use.  It provides
artificial limitations (only one request in flight at a time, per request
object).  It's ugly and confusing syntax wise (hard to keep track of which
request object is associated with which request method, requires multiple
statements to do each request, requires the handlers to be placed prior to
the actual call...which is why the async example in
http://www.w3.org/TR/IndexedDB/#introduction is so difficult to read, etc).
 And there really isn't any precedent (that I'm aware of) for using events
like this.  And the web developers I've spoken to have all been confused by
the async API.


I believe the API itself won't need to change much at all in order to make
callbacks work.  I'm happy to take a shot at making the necessary edits if
no one objects to changing the async API to a callback based one.

J

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
  On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
  mailto:k...@sitepen.com k...@sitepen.com wrote:
  [snip]

 
   The promises would only have a
  then method which would take in an
 
   onsuccess and onerror callback.  Both are optional.  The
  onsuccess
 
   function should take in a single parameter which matches the
  return
 
   value of the synchronous counterpart.  The onerror function
  should
 
   take in an IDBDatabaseError.  If the callbacks are null,
  undefined,
 
   or omitted, they're ignored.  If they're anything else, we should
 
   probably either raise an exception immediately or ignore them.
 
  Yes.
 
 
  Any thoughts on whether we'd raise or ignore improper inputs?  I'm
  leaning towards raise since it would be deterministic and silently
  ignoring seems like a headache from a developer standpoint.

 Throwing an error on improper inputs is fine with me.

 
 
   If there's an error, all onerror
  callbacks would be called with the
 
   IDBDatabaseError.
 
  Yes.
 
 
   Exceptions within callbacks
  would be ignored.
 
  With CommonJS promises, the promise returned by the then() call goes
  into an error state if a callback throws an exception. For example,
 
  someAsyncOperation.then(successHandler, function(){ throw new
  Error(test) })
  .then(null, function(error){ console.log(error); });
 
  Would log the thrown error, effectively giving you a way of catching
  the error.
 
  Are you suggesting this as a simplification so that IndexedDB impls
  doesn't have to worry about recursive creation of promises? If so, I
  suppose that seems like a reasonable simplification to me.
  Although if
  promises are something that could be potentially reused in other
  specs, it would be nice to have a quality solution, and I don't
  think
  this is a big implementation burden, I've implemented the recursive
  capabilities in dozen or two lines of JS code. But if burden is too
  onerous, I am fine with the simplification.
 
 
  When you say recursive capabilities are you just talking about how
  to handle exceptions, or something more?
 
  In terms of exceptions: I don't think it's an
  enormous implementational burden and thus I think it's fine to
  ignore that part of the equation.  So the question mainly comes down
  to whether the added complexity is worth it.  Can you think of any
  real-world examples of when this capability is useful in promises?
   If so, that'd definitely help us understand the pro's and con's.

 Maybe I misunderstanding your suggestion. By recursive capability I
 meant having then() return a promise (that is fulfilled with the
 result of executing the callback), and I thought you were suggesting
 that instead, then() would not return a promise. If then() returns a
 promise, I think the returned promise should clearly go into an error
 state if the callback throws an error. The goal of promises is to
 asynchronously model computations, and if a computation throws, it
 should result in the associated promise entering error state. The
 promise returned by then() exists to represent the result of the
 execution of the callback, and so it should resolve to the value
 returned by the callback or an error if the callback throws. Silenty
 swallowing errors seems highly undesirable.

 Now if we are simplifying then() to not return a promise at all, than
 I would think callbacks would just behave like any other event
 listener in regards to uncaught errors.


You are quite right!  I misunderstood how this part of promises worked.

Is there excitement about speccing promises in general?  If not, it seems a
little odd to spec such a powerful mechanism into just IndexedDBand it
might be best to spec the simplified version of .then(): .then() will return
undefined, onsuccess/onerror's return values will be swallowed, and any
thrown exceptions will be thrown.

This should make it easy to make IndexedDB support full blown promises
if/whenever they're specced.  (It's not clear to me whether UA support for
them would offer enough advantages to warrant it.)

It sounds like you're OK with such an approach, Kris?

What do others think?

J


  
   In terms of speccing, I'm not sure if we can get away with
  speccing
 
   one promise interface or whether we'd need to create one for each
 
   type of promise.
 
  Certainly the intent of promises is that there is exists only one
  generic promise interface that can be reused everywhere, at
  least from
  the JS perspective, not sure if the extra type constraints in IDL
  demand multiple interfaces to model promise's effectively
  parameterized generic type form.
 
 
  Unfortunately, I 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 2:37 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
  On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
  mailto:k...@sitepen.com k...@sitepen.com wrote:
  [snip]

 
   The promises would only have a
  then method which would take in an
 
   onsuccess and onerror callback.  Both are optional.  The
  onsuccess
 
   function should take in a single parameter which matches the
  return
 
   value of the synchronous counterpart.  The onerror function
  should
 
   take in an IDBDatabaseError.  If the callbacks are null,
  undefined,
 
   or omitted, they're ignored.  If they're anything else, we should
 
   probably either raise an exception immediately or ignore them.
 
  Yes.
 
 
  Any thoughts on whether we'd raise or ignore improper inputs?  I'm
  leaning towards raise since it would be deterministic and silently
  ignoring seems like a headache from a developer standpoint.

 Throwing an error on improper inputs is fine with me.

 
 
   If there's an error, all onerror
  callbacks would be called with the
 
   IDBDatabaseError.
 
  Yes.
 
 
   Exceptions within callbacks
  would be ignored.
 
  With CommonJS promises, the promise returned by the then() call goes
  into an error state if a callback throws an exception. For example,
 
  someAsyncOperation.then(successHandler, function(){ throw new
  Error(test) })
  .then(null, function(error){ console.log(error); });
 
  Would log the thrown error, effectively giving you a way of catching
  the error.
 
  Are you suggesting this as a simplification so that IndexedDB impls
  doesn't have to worry about recursive creation of promises? If so, I
  suppose that seems like a reasonable simplification to me.
  Although if
  promises are something that could be potentially reused in other
  specs, it would be nice to have a quality solution, and I don't
  think
  this is a big implementation burden, I've implemented the recursive
  capabilities in dozen or two lines of JS code. But if burden is too
  onerous, I am fine with the simplification.
 
 
  When you say recursive capabilities are you just talking about how
  to handle exceptions, or something more?
 
  In terms of exceptions: I don't think it's an
  enormous implementational burden and thus I think it's fine to
  ignore that part of the equation.  So the question mainly comes down
  to whether the added complexity is worth it.  Can you think of any
  real-world examples of when this capability is useful in promises?
   If so, that'd definitely help us understand the pro's and con's.

 Maybe I misunderstanding your suggestion. By recursive capability I
 meant having then() return a promise (that is fulfilled with the
 result of executing the callback), and I thought you were suggesting
 that instead, then() would not return a promise. If then() returns a
 promise, I think the returned promise should clearly go into an error
 state if the callback throws an error. The goal of promises is to
 asynchronously model computations, and if a computation throws, it
 should result in the associated promise entering error state. The
 promise returned by then() exists to represent the result of the
 execution of the callback, and so it should resolve to the value
 returned by the callback or an error if the callback throws. Silenty
 swallowing errors seems highly undesirable.

 Now if we are simplifying then() to not return a promise at all, than
 I would think callbacks would just behave like any other event
 listener in regards to uncaught errors.


 You are quite right!  I misunderstood how this part of promises worked.

 Is there excitement about speccing promises in general?  If not, it seems a
 little odd to spec such a powerful mechanism into just IndexedDBand it
 might be best to spec the simplified version of .then(): .then() will return
 undefined, onsuccess/onerror's return values will be swallowed, and any
 thrown exceptions will be thrown.


Erthrown exceptions will be _swallowed_ (not thrown).


 This should make it easy to make IndexedDB support full blown promises
 if/whenever they're specced.  (It's not clear to me whether UA support for
 them would offer enough advantages to warrant it.)

 It sounds like you're OK with such an approach, Kris?

 What do others think?

 J


  
   In terms of speccing, I'm not sure if we can get away with
  speccing
 
   one promise interface or whether we'd need to create one for each
 
   type of promise.
 
  Certainly the intent of promises is that there is exists only one
  generic promise interface that can be reused everywhere, at
  least from
  the JS perspective, not sure if the extra type 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Mark S. Miller]

On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org wrote:

 You are quite right!  I misunderstood how this part of promises worked.

 Is there excitement about speccing promises in general?


Yes. The starting point for a lot of the commonjs promises work is Tyler's
ref_send promise library, documented at 
http://waterken.sourceforge.net/web_send/#Q. The commonjs work got more
complicated than this in order to try to accommodate legacy deferred-based
usage patterns within the same framework. While it may have helped adoption
within the commonjs community, IMO this extra complexity should not be in
any standard promise spec. Caja implements Tyler's spec without the extra
complexity, and we're quite happy with it.

I hope to work with Tyler and others to propose this to the EcmaScript
committee as part of a more general proposal for a communicating-event-loops
concurrency and distribution framework for future EcmaScript. Don't hold
your breath though, this is not yet even an EcmaScript strawman. Neither is
there any general consensus on the EcmaScript committee that EcmaScript
should be extended in these directions. In the meantime, I suggest just
using Tyler's ref_send and web_send libraries.



  If not, it seems a little odd to spec such a powerful mechanism into just
 IndexedDBand it might be best to spec the simplified version of
 .then(): .then() will return undefined, onsuccess/onerror's return values
 will be swallowed, and any thrown exceptions will be thrown.

 This should make it easy to make IndexedDB support full blown promises
 if/whenever they're specced.  (It's not clear to me whether UA support for
 them would offer enough advantages to warrant it.)


Note that ref_send exposes the .then() style functionality as a static
.when() method on Q rather than an instance .then() method on promises. This
is important, as it 1) allows resolved values to be used where a promise is
expected, and 2) it protects the caller from interleavings happening during
their Q.when() call, even if the alleged promise they are operating on is
something else.





 It sounds like you're OK with such an approach, Kris?

 What do others think?

 J


  
   In terms of speccing, I'm not sure if we can get away with
  speccing
 
   one promise interface or whether we'd need to create one for each
 
   type of promise.
 
  Certainly the intent of promises is that there is exists only one
  generic promise interface that can be reused everywhere, at
  least from
  the JS perspective, not sure if the extra type constraints in IDL
  demand multiple interfaces to model promise's effectively
  parameterized generic type form.
 
 
  Unfortunately, I don't really know.  Before we try speccing it, I'll
  definitely see if any WebIDL experts have suggestions.
 
 
  Also, do we want to explicitly spec what happens in the following case?
 
  window.indexedDB.open(...).then(
  function(db) {  db.openObjectStore(a).then( function(os) {
  alert(Opened a); } ) }
  ).then(
  function(db) { alert(Second db opened); }
  );
 
  Clearly the first function(db) is called first.  But the question is
  whether it'd be a race of which alert is called first or whether the
  Second db opened alert should always be shown first (since clearly
  if the first is called, the second _can_ be fired immediately
  afterwards).
 
  I'm on the fence about whether it'd be useful to spec that the
  entire chain needs to be called one after the other before calling
  any other callbacks.  Does anyone have thoughts on whether this is
  useful or not?  If we do spec it to call the entire chain, then what
  happens if inside one of the callbacks, something is added to the
  chain (via another .then() call).
 
 Specing the order of multiple events in the event loop seems like it
 would be excessive burden on implementors, IMO.

  I've been talking to a co-worker here who seems to know a decent
  amount about promises (as implemented in E) and some about differed
  (as implemented in Python's Twisted library).  From talking to him,
  it seems that my original suggestion for not handling exceptions
  thrown inside a .then() callback is the way to go.
 
  It seems as though promises put a lot of weight on composability and
  making it so that the order of .then() calls not mattering.  This
  means that you can then pass promises to other async interfaces and
  not have to worry about different timings leading to different
  results.  It also means that if you pass a promise into multiple
  consumers (say, javascript libraries) you don't need to worry about
  one using a promise in a way that screws up another.
 
  Differed seems to be more expressive and flexible.  For example,
  instead of doing this:
 
  window.indexedDB.open(...).then(
  function(db) {  db.openObjectStore(a).then(
  function(os) { os.get(x).then(
  function(value) { alert(Value:  + value); }
  ) }
  

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 10:35 AM, Mark S. Miller wrote:
 On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org
 mailto:jor...@chromium.org wrote:

 You are quite right!  I misunderstood how this part of promises
 worked.

 Is there excitement about speccing promises in general?


 Yes. The starting point for a lot of the commonjs promises work is
 Tyler's ref_send promise library, documented at
 http://waterken.sourceforge.net/web_send/#Q. The commonjs work
 got more complicated than this in order to try to accommodate
 legacy deferred-based usage patterns within the same framework.
 While it may have helped adoption within the commonjs community,
 IMO this extra complexity should not be in any standard promise
 spec. Caja implements Tyler's spec without the extra complexity,
 and we're quite happy with it.

 I hope to work with Tyler and others to propose this to the
 EcmaScript committee as part of a more general proposal for a
 communicating-event-loops concurrency and distribution framework
 for future EcmaScript. Don't hold your breath though, this is not
 yet even an EcmaScript strawman. Neither is there any general
 consensus on the EcmaScript committee that EcmaScript should be
 extended in these directions. In the meantime, I suggest just using
 Tyler's ref_send and web_send libraries.

It would be great if promises become first class, but obviously the
IndexedDB specification can't be dependent on someone's JS library.



 If not, it seems a little odd to spec such a powerful mechanism
 into just IndexedDBand it might be best to spec the simplified
 version of .then(): .then() will return undefined,
 onsuccess/onerror's return values will be swallowed, and any thrown
 exceptions will be thrown.

 This should make it easy to make IndexedDB support full blown
 promises if/whenever they're specced.  (It's not clear to me
 whether UA support for them would offer enough advantages to
 warrant it.)


 Note that ref_send exposes the .then() style functionality as a
 static .when() method on Q rather than an instance .then() method
 on promises. This is important, as it 1) allows resolved values to
 be used where a promise is expected, and 2) it protects the caller
 from interleavings happening during their Q.when() call, even if
 the alleged promise they are operating on is something else.

The .then() function is in no way intended to be a replacement for a
static .when() function. In contrast to ref_send, having promises
defined by having a .then() function is in lieu of ref_send's
definition of a promise where the promise is a function that must be
called:
promise(WHEN, callback, errback);
This group can consider it an API like this, but I don't think that
IndexedDB or any other W3C API would want to define promises in that
way, as it is pretty awkward. Using .then() based promises in no way
precludes the use of Q.when() implementations which meet both your
criteria for safe operation. However, these can easily be implemented
in JS, and I don't think the IndexedDB API needs to worry about such
promise libraries.

- -- 
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/
 
iEYEARECAAYFAkuP8f0ACgkQ9VpNnHc4zAwm9gCfajBUy0PZpaxvSctlorVeYIsK
yQwAnAwtSd6BWPbpOOJTniZcojmNFQtw
=GHjA
-END PGP SIGNATURE-

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Aaron Boodman]

On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com wrote:
 On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote:

 * 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

 Very interesting.  The general concept seems promising and fairly flexible.
  You can easily code in a similar style to normal async/callback semantics,
 but it seems like you have a lot more flexibility.  I do have a few
 questions though.
 Are there any good examples of these used in the wild that you can point me
 towards?  I used my imagination for prototyping up some examples, but it'd
 be great to see some real examples + be able to see the exact semantics used
 in those implementations.
 I see that you can supply an error handling callback to .then(), but does
 that only apply to the one operation?  I could easily imagine emulating
 try/catch type semantics and have errors continue down the line of .then's
 until someone handles it.  It might even make sense to allow the error
 handlers to re-raise (i.e. allow to bubble) errors so that later routines
 would get them as well.  Maybe you'd even want it to bubble by default?
  What have other implementations done with this stuff?  What is the most
 robust and least cumbersome for typical applications?  (And, in te complete
 absence of real experience, are there any expert opinions on what might
 work?)
 Overall this seems fairly promising and not that hard to implement.  Do
 others see pitfalls that I'm missing?
 J

I disagree that IndexedDB should use promises, for several reasons:

* Promises are only really useful when they are used ubiquitously
throughout the platform, so that you can pass them around like
references. In libraries like Dojo, MochiKit, and Twisted, this is
exactly the situation. But in the web platform, this would be the
first such API. Without places to pass a promise to, all you really
have is a lot of additional complexity.

* ISTM that the entire space is still evolving quite rapidly. Many
JavaScript libraries have implemented a form of this, and this
proposal is also slightly different from any of them. I think it is
premature to have browsers implement this while library authors are
still hashing out best practice. Once it is in browsers, it's forever.

* There is nothing preventing JS authors from implementing a
promise-style API on top of IndexedDB, if that is what they want to
do.

- a

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 5:46 PM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/4/2010 10:35 AM, Mark S. Miller wrote:
  On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org
  mailto:jor...@chromium.org jor...@chromium.org wrote:
 
  You are quite right!  I misunderstood how this part of promises
  worked.
 
  Is there excitement about speccing promises in general?
 
 
  Yes. The starting point for a lot of the commonjs promises work is
  Tyler's ref_send promise library, documented at
  http://waterken.sourceforge.net/web_send/#Qhttp://waterken.sourceforge.net/web_send/#Q.
 The commonjs work
  got more complicated than this in order to try to accommodate
  legacy deferred-based usage patterns within the same framework.
  While it may have helped adoption within the commonjs community,
  IMO this extra complexity should not be in any standard promise
  spec. Caja implements Tyler's spec without the extra complexity,
  and we're quite happy with it.
 
  I hope to work with Tyler and others to propose this to the
  EcmaScript committee as part of a more general proposal for a
  communicating-event-loops concurrency and distribution framework
  for future EcmaScript. Don't hold your breath though, this is not
  yet even an EcmaScript strawman. Neither is there any general
  consensus on the EcmaScript committee that EcmaScript should be
  extended in these directions. In the meantime, I suggest just using
  Tyler's ref_send and web_send libraries.


 It would be great if promises become first class, but obviously the
 IndexedDB specification can't be dependent on someone's JS library.

 
 
 
  If not, it seems a little odd to spec such a powerful mechanism
  into just IndexedDBand it might be best to spec the simplified
  version of .then(): .then() will return undefined,
  onsuccess/onerror's return values will be swallowed, and any thrown
  exceptions will be thrown.
 
  This should make it easy to make IndexedDB support full blown
  promises if/whenever they're specced.  (It's not clear to me
  whether UA support for them would offer enough advantages to
  warrant it.)
 
 
  Note that ref_send exposes the .then() style functionality as a
  static .when() method on Q rather than an instance .then() method
  on promises. This is important, as it 1) allows resolved values to
  be used where a promise is expected, and 2) it protects the caller
  from interleavings happening during their Q.when() call, even if
  the alleged promise they are operating on is something else.


Thanks a lot for your feedback!  This is very valuable and definitely
provided some food for thought.  I started working on a rambly email about
the pro's and cons of when when I saw Kris's response.


 The .then() function is in no way intended to be a replacement for a
 static .when() function. In contrast to ref_send, having promises
 defined by having a .then() function is in lieu of ref_send's
 definition of a promise where the promise is a function that must be
 called:
 promise(WHEN, callback, errback);
 This group can consider it an API like this, but I don't think that
 IndexedDB or any other W3C API would want to define promises in that
 way, as it is pretty awkward. Using .then() based promises in no way
 precludes the use of Q.when() implementations which meet both your
 criteria for safe operation. However, these can easily be implemented
 in JS, and I don't think the IndexedDB API needs to worry about such
 promise libraries.


Which is basically what I had arrived at in my mind as well.

It'll definitely be interesting to see how the EMCAScript side of promises
shapes up.  But in the mean time, I think the simpler version that we've
been discussing will be a good balance of features but minimized API surface
area...and keeping chances high that what ends up being standardized would
fit in well with the API.

At this point, I feel fairly confident that using a scaled down version of
promises would work well in IndexedDB.  But, at the same time, a callback
based API would be much more standard and it wouldn't be that hard for
someone to build a promise based library around IndexedDB.  Nikunj, Pablo,
Mozilla, etc...what do you think is the best way forward here?  Should we
give scaled back promises a shot?  Or should we just go with a callback
based approach?

J


Summary of what I'm currently thinking we should do, if we go with a
Promises type async API:

Each async function would return a promise.  A promise has one method:
.then().  Then takes up to two callbacks. The first is onsuccess.  The
second is onerror.  You can call .then() before and after the async call has
finished--in fact, there's no way to know for sure whether it has finished
before you call .then() (but that's fine).  If you pass in garbage to the
callbacks, it'll throw an exception, but null/undefined and omitting them is
fine.  When the promise is ready to fire the callbacks, it'll always do it

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 11:08 AM, Aaron Boodman wrote:
 On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com
 wrote:
 On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
 wrote:

 * 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

 Very interesting.  The general concept seems promising and fairly
 flexible. You can easily code in a similar style to normal
 async/callback semantics, but it seems like you have a lot more
 flexibility.  I do have a few questions though. Are there any
 good examples of these used in the wild that you can point me
 towards?  I used my imagination for prototyping up some examples,
 but it'd be great to see some real examples + be able to see the
 exact semantics used in those implementations. I see that you can
 supply an error handling callback to .then(), but does that only
 apply to the one operation?  I could easily imagine emulating
 try/catch type semantics and have errors continue down the line
 of .then's until someone handles it.  It might even make sense to
 allow the error handlers to re-raise (i.e. allow to bubble)
 errors so that later routines would get them as well.  Maybe
 you'd even want it to bubble by default? What have other
 implementations done with this stuff?  What is the most robust
 and least cumbersome for typical applications?  (And, in te
 complete absence of real experience, are there any expert
 opinions on what might work?) Overall this seems fairly promising
 and not that hard to implement.  Do others see pitfalls that I'm
 missing? J

 I disagree that IndexedDB should use promises, for several
 reasons:

 * Promises are only really useful when they are used ubiquitously
 throughout the platform, so that you can pass them around like
 references. In libraries like Dojo, MochiKit, and Twisted, this is
 exactly the situation. But in the web platform, this would be the
 first such API. Without places to pass a promise to, all you
 really have is a lot of additional complexity.

I certainly agree that promises are more useful when used
ubiquitously. However, promises have many advantages besides just
being a common interface for asynchronous operations, including
interface simplicity, composibility, and separation of concerns. But,
your point about this being the first such API is really important. If
we are going to use promises in the IndexedDB, I think they should the
webapps group should be looking at them beyond the scope of just the
IndexedDB API, and how they could be used in other APIs, such that
common interface advantage could be realized. Looking at the broad
perspective is key here.

 * ISTM that the entire space is still evolving quite rapidly. Many
 JavaScript libraries have implemented a form of this, and this
 proposal is also slightly different from any of them. I think it
 is premature to have browsers implement this while library authors
 are still hashing out best practice. Once it is in browsers, it's
 forever.
Promises have been around for a number of years, we already have a lot
of experience to draw from, this isn't exactly a brand new idea,
promises are a well-established concept. The CommonJS proposal is
nothing ground breaking, it is more based on the culmination of ideas
of Dojo, ref_send and others. It is also worth noting that a number of
JS libraries have expressed interest in moving towards the CommonJS
promise proposal, and Dojo will probably support them in 1.5.

 * There is nothing preventing JS authors from implementing a
 promise-style API on top of IndexedDB, if that is what they want
 to do.

Yes, you can always make an API harder to use so that JS authors have
more they can do with it ;). But it is true, we can build promises on
top of an plain event-based

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Nikunj Mehta]

On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:



On 3/4/2010 11:08 AM, Aaron Boodman wrote:

On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com
wrote:

On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
wrote:


* 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


Very interesting.  The general concept seems promising and fairly
flexible. You can easily code in a similar style to normal
async/callback semantics, but it seems like you have a lot more
flexibility.  I do have a few questions though. Are there any
good examples of these used in the wild that you can point me
towards?  I used my imagination for prototyping up some examples,
but it'd be great to see some real examples + be able to see the
exact semantics used in those implementations. I see that you can
supply an error handling callback to .then(), but does that only
apply to the one operation?  I could easily imagine emulating
try/catch type semantics and have errors continue down the line
of .then's until someone handles it.  It might even make sense to
allow the error handlers to re-raise (i.e. allow to bubble)
errors so that later routines would get them as well.  Maybe
you'd even want it to bubble by default? What have other
implementations done with this stuff?  What is the most robust
and least cumbersome for typical applications?  (And, in te
complete absence of real experience, are there any expert
opinions on what might work?) Overall this seems fairly promising
and not that hard to implement.  Do others see pitfalls that I'm
missing? J


I disagree that IndexedDB should use promises, for several
reasons:

* Promises are only really useful when they are used ubiquitously
throughout the platform, so that you can pass them around like
references. In libraries like Dojo, MochiKit, and Twisted, this is
exactly the situation. But in the web platform, this would be the
first such API. Without places to pass a promise to, all you
really have is a lot of additional complexity.


I certainly agree that promises are more useful when used
ubiquitously. However, promises have many advantages besides just
being a common interface for asynchronous operations, including
interface simplicity, composibility, and separation of concerns. But,
your point about this being the first such API is really important. If
we are going to use promises in the IndexedDB, I think they should the
webapps group should be looking at them beyond the scope of just the
IndexedDB API, and how they could be used in other APIs, such that
common interface advantage could be realized. Looking at the broad
perspective is key here.


In general, IndexedDB has taken an approach of leaving ease of  
programming to libraries. There seems to be a good case to build  
libraries to make asynchronous programming with IndexedDB easier  
through the use of such mechanisms as promises. In fact, IndexedDB  
might be yet another area for libraries to slug it out.




* ISTM that the entire space is still evolving quite rapidly. Many
JavaScript libraries have implemented a form of this, and this
proposal is also slightly different from any of them. I think it
is premature to have browsers implement this while library authors
are still hashing out best practice. Once it is in browsers, it's
forever.

Promises have been around for a number of years, we already have a lot
of experience to draw from, this isn't exactly a brand new idea,
promises are a well-established concept. The CommonJS proposal is
nothing ground breaking, it is more based on the culmination of ideas
of Dojo, ref_send and others. It is also worth noting that a number of
JS libraries have expressed interest in moving towards the CommonJS
promise proposal, and Dojo will probably support them in 1.5.


I feel that we should avoid

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Thu, Mar 4, 2010 at 6:46 PM, Nikunj Mehta nik...@o-micron.com wrote:


 On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:


 On 3/4/2010 11:08 AM, Aaron Boodman wrote:

 On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com
 wrote:

 On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
 wrote:


 * 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


 Very interesting.  The general concept seems promising and fairly
 flexible. You can easily code in a similar style to normal
 async/callback semantics, but it seems like you have a lot more
 flexibility.  I do have a few questions though. Are there any
 good examples of these used in the wild that you can point me
 towards?  I used my imagination for prototyping up some examples,
 but it'd be great to see some real examples + be able to see the
 exact semantics used in those implementations. I see that you can
 supply an error handling callback to .then(), but does that only
 apply to the one operation?  I could easily imagine emulating
 try/catch type semantics and have errors continue down the line
 of .then's until someone handles it.  It might even make sense to
 allow the error handlers to re-raise (i.e. allow to bubble)
 errors so that later routines would get them as well.  Maybe
 you'd even want it to bubble by default? What have other
 implementations done with this stuff?  What is the most robust
 and least cumbersome for typical applications?  (And, in te
 complete absence of real experience, are there any expert
 opinions on what might work?) Overall this seems fairly promising
 and not that hard to implement.  Do others see pitfalls that I'm
 missing? J


 I disagree that IndexedDB should use promises, for several
 reasons:

 * Promises are only really useful when they are used ubiquitously
 throughout the platform, so that you can pass them around like
 references. In libraries like Dojo, MochiKit, and Twisted, this is
 exactly the situation. But in the web platform, this would be the
 first such API. Without places to pass a promise to, all you
 really have is a lot of additional complexity.


 I certainly agree that promises are more useful when used
 ubiquitously. However, promises have many advantages besides just
 being a common interface for asynchronous operations, including
 interface simplicity, composibility, and separation of concerns. But,
 your point about this being the first such API is really important. If
 we are going to use promises in the IndexedDB, I think they should the
 webapps group should be looking at them beyond the scope of just the
 IndexedDB API, and how they could be used in other APIs, such that
 common interface advantage could be realized. Looking at the broad
 perspective is key here.


 In general, IndexedDB has taken an approach of leaving ease of programming
 to libraries. There seems to be a good case to build libraries to make
 asynchronous programming with IndexedDB easier through the use of such
 mechanisms as promises. In fact, IndexedDB might be yet another area for
 libraries to slug it out.



 * ISTM that the entire space is still evolving quite rapidly. Many
 JavaScript libraries have implemented a form of this, and this
 proposal is also slightly different from any of them. I think it
 is premature to have browsers implement this while library authors
 are still hashing out best practice. Once it is in browsers, it's
 forever.

 Promises have been around for a number of years, we already have a lot
 of experience to draw from, this isn't exactly a brand new idea,
 promises are a well-established concept. The CommonJS proposal is
 nothing ground breaking, it is more based on the culmination of ideas
 of Dojo, ref_send and others. It is also worth noting that a number of
 JS libraries

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/4/2010 11:46 AM, Nikunj Mehta wrote:

 On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:


 On 3/4/2010 11:08 AM, Aaron Boodman wrote:
 [snip]

 * There is nothing preventing JS authors from implementing a
 promise-style API on top of IndexedDB, if that is what they
 want to do.

 Yes, you can always make an API harder to use so that JS authors
 have more they can do with it ;).

 You will agree that we don't want to wait for one style of
 promises to win out over others before IndexedDB can be made
 available to programmers. Till the soil and let a thousand flowers
 bloom.

The IndexedDB spec isn't and can't just sit back and not define the
asynchronous interface. Like it or not, IndexedDB has defined a
promise-like entity with the |DBRequest| interface. Why is inventing a
new (and somewhat ugly) flower better than designing based on the many
flowers that have already bloomed?

- -- 
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/
 
iEYEARECAAYFAkuQAiUACgkQ9VpNnHc4zAzZkgCeIjAVz56S3sR5BeKt8lZPGMJo
6rYAoJ4x4WJN9W9LhdXkbbJaT94A8/om
=oJbA
-END PGP SIGNATURE-

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Nikunj Mehta]

On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote:


On 3/4/2010 11:46 AM, Nikunj Mehta wrote:

  On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote:
 
 
  On 3/4/2010 11:08 AM, Aaron Boodman wrote:
  [snip]
 
  * There is nothing preventing JS authors from implementing a
  promise-style API on top of IndexedDB, if that is what they
  want to do.
 
  Yes, you can always make an API harder to use so that JS authors
  have more they can do with it ;).
 
  You will agree that we don't want to wait for one style of
  promises to win out over others before IndexedDB can be made
  available to programmers. Till the soil and let a thousand flowers
  bloom.

The IndexedDB spec isn't and can't just sit back and not define the
asynchronous interface. Like it or not, IndexedDB has defined a
promise-like entity with the |DBRequest| interface. Why is inventing a
new (and somewhat ugly) flower better than designing based on the many
flowers that have already bloomed?


I meant to say that the IndexedDB spec should be updated to use a  
model that supports promises. If the current one is not adequate then,  
by all means, let's make it. However, we don't need a full-fledged  
promises in IndexedDB. I hope you agree this time.

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
  Thanks for the pointers.  I'm actually pretty sold on the general
  idea of promises, and my intuition is that there won't be a very
  big resource penalty for using an API like this rather than
  callbacks or what's currently specced.  At the same time, it seems
  as though there isn't much of a standard in terms of the precise
  semantics and some of the techniques (such as optionally taking
  callbacks and not returning a promise if they are supplied) seems
  like a decent answer for pure javascript APIs, but maybe not as
  good for IDL and a standard like this.
 
  Do you guys have any recommendations for the precise semantics we'd
  use, if we used promises in IndexedDB?  To get started, let me list
  what I'd propose and maybe you can offer counter proposals or
  feedback on what would or wouldn't work?
 
 
  Each method on a Request interface (the async ones in the spec)
  whose counterpart returns something other than void would instead
  return a Promise.

 Asynchronous counterparts to void-returning synchronous functions can
 still return promises. The promise would just resolve to undefined,
 but it still fulfills the role of indicating when the operation is
 complete.


Good point!  Silly me.


   The promises would only have a then method which would take in an
  onsuccess and onerror callback.  Both are optional.  The onsuccess
  function should take in a single parameter which matches the return
  value of the synchronous counterpart.  The onerror function should
  take in an IDBDatabaseError.  If the callbacks are null, undefined,
  or omitted, they're ignored.  If they're anything else, we should
  probably either raise an exception immediately or ignore them.

 Yes.


Any thoughts on whether we'd raise or ignore improper inputs?  I'm leaning
towards raise since it would be deterministic and silently ignoring seems
like a headache from a developer standpoint.


  If there's an error, all onerror callbacks would be called with the
  IDBDatabaseError.

 Yes.


  Exceptions within callbacks would be ignored.

 With CommonJS promises, the promise returned by the then() call goes
 into an error state if a callback throws an exception. For example,

 someAsyncOperation.then(successHandler, function(){ throw new
 Error(test) })
 .then(null, function(error){ console.log(error); });

 Would log the thrown error, effectively giving you a way of catching
 the error.

 Are you suggesting this as a simplification so that IndexedDB impls
 doesn't have to worry about recursive creation of promises? If so, I
 suppose that seems like a reasonable simplification to me. Although if
 promises are something that could be potentially reused in other
 specs, it would be nice to have a quality solution, and I don't think
 this is a big implementation burden, I've implemented the recursive
 capabilities in dozen or two lines of JS code. But if burden is too
 onerous, I am fine with the simplification.


When you say recursive capabilities are you just talking about how to
handle exceptions, or something more?

In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to ignore that
part of the equation.  So the question mainly comes down to whether the
added complexity is worth it.  Can you think of any real-world examples of
when this capability is useful in promises?  If so, that'd definitely help
us understand the pro's and con's.

 In terms of speccing, I'm not sure if we can get away with speccing
  one promise interface or whether we'd need to create one for each
  type of promise.

 Certainly the intent of promises is that there is exists only one
 generic promise interface that can be reused everywhere, at least from
 the JS perspective, not sure if the extra type constraints in IDL
 demand multiple interfaces to model promise's effectively
 parameterized generic type form.


Unfortunately, I don't really know.  Before we try speccing it, I'll
definitely see if any WebIDL experts have suggestions.


Also, do we want to explicitly spec what happens in the following case?

window.indexedDB.open(...).then(
function(db) {  db.openObjectStore(a).then( function(os) {
alert(Opened a); } ) }
).then(
function(db) { alert(Second db opened); }
);

Clearly the first function(db) is called first.  But the question is whether
it'd be a race of which alert is called first or whether the Second db
opened alert should always be shown first (since clearly if the first is
called, the second _can_ be fired immediately afterwards).

I'm on the fence about whether it'd be useful to spec that the entire chain
needs to be called one after the other before calling any other callbacks.
 Does anyone have thoughts on whether this is useful or not?  If we do spec
it to call the entire chain, then what happens if 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Wed, Mar 3, 2010 at 11:01 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
  Thanks for the pointers.  I'm actually pretty sold on the general
  idea of promises, and my intuition is that there won't be a very
  big resource penalty for using an API like this rather than
  callbacks or what's currently specced.  At the same time, it seems
  as though there isn't much of a standard in terms of the precise
  semantics and some of the techniques (such as optionally taking
  callbacks and not returning a promise if they are supplied) seems
  like a decent answer for pure javascript APIs, but maybe not as
  good for IDL and a standard like this.
 
  Do you guys have any recommendations for the precise semantics we'd
  use, if we used promises in IndexedDB?  To get started, let me list
  what I'd propose and maybe you can offer counter proposals or
  feedback on what would or wouldn't work?
 
 
  Each method on a Request interface (the async ones in the spec)
  whose counterpart returns something other than void would instead
  return a Promise.

 Asynchronous counterparts to void-returning synchronous functions can
 still return promises. The promise would just resolve to undefined,
 but it still fulfills the role of indicating when the operation is
 complete.


 Good point!  Silly me.


   The promises would only have a then method which would take in an
  onsuccess and onerror callback.  Both are optional.  The onsuccess
  function should take in a single parameter which matches the return
  value of the synchronous counterpart.  The onerror function should
  take in an IDBDatabaseError.  If the callbacks are null, undefined,
  or omitted, they're ignored.  If they're anything else, we should
  probably either raise an exception immediately or ignore them.

 Yes.


 Any thoughts on whether we'd raise or ignore improper inputs?  I'm leaning
 towards raise since it would be deterministic and silently ignoring seems
 like a headache from a developer standpoint.


  If there's an error, all onerror callbacks would be called with the
  IDBDatabaseError.

 Yes.


  Exceptions within callbacks would be ignored.

 With CommonJS promises, the promise returned by the then() call goes
 into an error state if a callback throws an exception. For example,

 someAsyncOperation.then(successHandler, function(){ throw new
 Error(test) })
 .then(null, function(error){ console.log(error); });

 Would log the thrown error, effectively giving you a way of catching
 the error.

 Are you suggesting this as a simplification so that IndexedDB impls
 doesn't have to worry about recursive creation of promises? If so, I
 suppose that seems like a reasonable simplification to me. Although if
 promises are something that could be potentially reused in other
 specs, it would be nice to have a quality solution, and I don't think
 this is a big implementation burden, I've implemented the recursive
 capabilities in dozen or two lines of JS code. But if burden is too
 onerous, I am fine with the simplification.


 When you say recursive capabilities are you just talking about how to
 handle exceptions, or something more?

  In terms of exceptions: I don't think it's an
 enormous implementational burden and thus I think it's fine to ignore that
 part of the equation.  So the question mainly comes down to whether the
 added complexity is worth it.  Can you think of any real-world examples of
 when this capability is useful in promises?  If so, that'd definitely help
 us understand the pro's and con's.


I've been talking to a co-worker here who seems to know a decent amount
about promises (as implemented in E) and some about differed (as implemented
in Python's Twisted library).  From talking to him, it seems that my
original suggestion for not handling exceptions thrown inside a .then()
callback is the way to go.

It seems as though promises put a lot of weight on composability and making
it so that the order of .then() calls not mattering.  This means that you
can then pass promises to other async interfaces and not have to worry about
different timings leading to different results.  It also means that if you
pass a promise into multiple consumers (say, javascript libraries) you don't
need to worry about one using a promise in a way that screws up another.

Differed seems to be more expressive and flexible.  For example, instead of
doing this:

window.indexedDB.open(...).then(
function(db) {  db.openObjectStore(a).then(
function(os) { os.get(x).then(
function(value) { alert(Value:  + value); }
) }
) }
);

I could do this:

window.indexedDB.open(...).then(
function(db) { return db.openObjectStore(a); }// Note the return
value is passed on to the next step.
).then(
function(os) { return os.get(x); }
).then(
function(value) { 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

Erm...  s/differed/deferred/g

On Wed, Mar 3, 2010 at 4:58 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Mar 3, 2010 at 11:01 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
  Thanks for the pointers.  I'm actually pretty sold on the general
  idea of promises, and my intuition is that there won't be a very
  big resource penalty for using an API like this rather than
  callbacks or what's currently specced.  At the same time, it seems
  as though there isn't much of a standard in terms of the precise
  semantics and some of the techniques (such as optionally taking
  callbacks and not returning a promise if they are supplied) seems
  like a decent answer for pure javascript APIs, but maybe not as
  good for IDL and a standard like this.
 
  Do you guys have any recommendations for the precise semantics we'd
  use, if we used promises in IndexedDB?  To get started, let me list
  what I'd propose and maybe you can offer counter proposals or
  feedback on what would or wouldn't work?
 
 
  Each method on a Request interface (the async ones in the spec)
  whose counterpart returns something other than void would instead
  return a Promise.

 Asynchronous counterparts to void-returning synchronous functions can
 still return promises. The promise would just resolve to undefined,
 but it still fulfills the role of indicating when the operation is
 complete.


 Good point!  Silly me.


   The promises would only have a then method which would take in an
  onsuccess and onerror callback.  Both are optional.  The onsuccess
  function should take in a single parameter which matches the return
  value of the synchronous counterpart.  The onerror function should
  take in an IDBDatabaseError.  If the callbacks are null, undefined,
  or omitted, they're ignored.  If they're anything else, we should
  probably either raise an exception immediately or ignore them.

 Yes.


 Any thoughts on whether we'd raise or ignore improper inputs?  I'm leaning
 towards raise since it would be deterministic and silently ignoring seems
 like a headache from a developer standpoint.


  If there's an error, all onerror callbacks would be called with the
  IDBDatabaseError.

 Yes.


  Exceptions within callbacks would be ignored.

 With CommonJS promises, the promise returned by the then() call goes
 into an error state if a callback throws an exception. For example,

 someAsyncOperation.then(successHandler, function(){ throw new
 Error(test) })
 .then(null, function(error){ console.log(error); });

 Would log the thrown error, effectively giving you a way of catching
 the error.

 Are you suggesting this as a simplification so that IndexedDB impls
 doesn't have to worry about recursive creation of promises? If so, I
 suppose that seems like a reasonable simplification to me. Although if
 promises are something that could be potentially reused in other
 specs, it would be nice to have a quality solution, and I don't think
 this is a big implementation burden, I've implemented the recursive
 capabilities in dozen or two lines of JS code. But if burden is too
 onerous, I am fine with the simplification.


 When you say recursive capabilities are you just talking about how to
 handle exceptions, or something more?

  In terms of exceptions: I don't think it's an
 enormous implementational burden and thus I think it's fine to ignore that
 part of the equation.  So the question mainly comes down to whether the
 added complexity is worth it.  Can you think of any real-world examples of
 when this capability is useful in promises?  If so, that'd definitely help
 us understand the pro's and con's.


 I've been talking to a co-worker here who seems to know a decent amount
 about promises (as implemented in E) and some about differed (as implemented
 in Python's Twisted library).  From talking to him, it seems that my
 original suggestion for not handling exceptions thrown inside a .then()
 callback is the way to go.

 It seems as though promises put a lot of weight on composability and making
 it so that the order of .then() calls not mattering.  This means that you
 can then pass promises to other async interfaces and not have to worry about
 different timings leading to different results.  It also means that if you
 pass a promise into multiple consumers (say, javascript libraries) you don't
 need to worry about one using a promise in a way that screws up another.

 Differed seems to be more expressive and flexible.  For example, instead of
 doing this:

 window.indexedDB.open(...).then(
 function(db) {  db.openObjectStore(a).then(
 function(os) { os.get(x).then(
 function(value) { alert(Value:  + value); }
 ) }
 ) }
 );

 I could do this:

 window.indexedDB.open(...).then(
 function(db) { return db.openObjectStore(a); }// Note 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
 On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
 mailto:k...@sitepen.com wrote:
 [snip]

  The promises would only have a
 then method which would take in an

  onsuccess and onerror callback.  Both are optional.  The
 onsuccess

  function should take in a single parameter which matches the
 return

  value of the synchronous counterpart.  The onerror function
 should

  take in an IDBDatabaseError.  If the callbacks are null,
 undefined,

  or omitted, they're ignored.  If they're anything else, we should

  probably either raise an exception immediately or ignore them.

 Yes.


 Any thoughts on whether we'd raise or ignore improper inputs?  I'm
 leaning towards raise since it would be deterministic and silently
 ignoring seems like a headache from a developer standpoint.
Throwing an error on improper inputs is fine with me.
 

  If there's an error, all onerror
 callbacks would be called with the

  IDBDatabaseError.

 Yes.


  Exceptions within callbacks
 would be ignored.

 With CommonJS promises, the promise returned by the then() call goes
 into an error state if a callback throws an exception. For example,

 someAsyncOperation.then(successHandler, function(){ throw new
 Error(test) })
 .then(null, function(error){ console.log(error); });

 Would log the thrown error, effectively giving you a way of catching
 the error.

 Are you suggesting this as a simplification so that IndexedDB impls
 doesn't have to worry about recursive creation of promises? If so, I
 suppose that seems like a reasonable simplification to me.
 Although if
 promises are something that could be potentially reused in other
 specs, it would be nice to have a quality solution, and I don't
 think
 this is a big implementation burden, I've implemented the recursive
 capabilities in dozen or two lines of JS code. But if burden is too
 onerous, I am fine with the simplification.


 When you say recursive capabilities are you just talking about how
 to handle exceptions, or something more?

 In terms of exceptions: I don't think it's an
 enormous implementational burden and thus I think it's fine to
 ignore that part of the equation.  So the question mainly comes down
 to whether the added complexity is worth it.  Can you think of any
 real-world examples of when this capability is useful in promises?
  If so, that'd definitely help us understand the pro's and con's.

Maybe I misunderstanding your suggestion. By recursive capability I
meant having then() return a promise (that is fulfilled with the
result of executing the callback), and I thought you were suggesting
that instead, then() would not return a promise. If then() returns a
promise, I think the returned promise should clearly go into an error
state if the callback throws an error. The goal of promises is to
asynchronously model computations, and if a computation throws, it
should result in the associated promise entering error state. The
promise returned by then() exists to represent the result of the
execution of the callback, and so it should resolve to the value
returned by the callback or an error if the callback throws. Silenty
swallowing errors seems highly undesirable.

Now if we are simplifying then() to not return a promise at all, than
I would think callbacks would just behave like any other event
listener in regards to uncaught errors.

  In terms of speccing, I'm not sure if we can get away with
 speccing

  one promise interface or whether we'd need to create one for each

  type of promise.

 Certainly the intent of promises is that there is exists only one
 generic promise interface that can be reused everywhere, at
 least from
 the JS perspective, not sure if the extra type constraints in IDL
 demand multiple interfaces to model promise's effectively
 parameterized generic type form.


 Unfortunately, I don't really know.  Before we try speccing it, I'll
 definitely see if any WebIDL experts have suggestions.


 Also, do we want to explicitly spec what happens in the following case?

 window.indexedDB.open(...).then(
 function(db) {  db.openObjectStore(a).then( function(os) {
 alert(Opened a); } ) }
 ).then(
 function(db) { alert(Second db opened); }
 );

 Clearly the first function(db) is called first.  But the question is
 whether it'd be a race of which alert is called first or whether the
 Second db opened alert should always be shown first (since clearly
 if the first is called, the second _can_ be fired immediately
 afterwards).

 I'm on the fence about whether it'd be useful to spec that the
 entire chain needs to be called one after the other before calling
 any other callbacks.  Does anyone have thoughts on whether this is
 useful or not?  If we do spec it 

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Mon, Mar 1, 2010 at 9:52 PM, Jeremy Orlow jor...@chromium.org wrote:

 Thanks for the pointers.  I'm actually pretty sold on the general idea of
 promises, and my intuition is that there won't be a very big resource
 penalty for using an API like this rather than callbacks or what's currently
 specced.  At the same time, it seems as though there isn't much of a
 standard in terms of the precise semantics and some of the techniques (such
 as optionally taking callbacks and not returning a promise if they are
 supplied) seems like a decent answer for pure javascript APIs, but maybe not
 as good for IDL and a standard like this.

 Do you guys have any recommendations for the precise semantics we'd use, if
 we used promises in IndexedDB?  To get started, let me list what I'd propose
 and maybe you can offer counter proposals or feedback on what would or
 wouldn't work?


 Each method on a Request interface (the async ones in the spec) whose
 counterpart returns something other than void would instead return a
 Promise.

 The promises would only have a then method which would take in an
 onsuccess and onerror callback.  Both are optional.  The onsuccess function
 should take in a single parameter which matches the return value of the
 synchronous counterpart.  The onerror function should take in an
 IDBDatabaseError.  If the callbacks are null, undefined, or omitted, they're
 ignored.  If they're anything else, we should probably either raise an
 exception immediately or ignore them.

 If there's an error, all onerror callbacks would be called with the
 IDBDatabaseError.

 Exceptions within callbacks would be ignored.


Oh.  And the callbacks should probably be enqueued in the main event loop
when the result/error is ready.  This way, even if the result is already
available when .then() is called, an implementation won't simply call the
callback immediately (in a nested fashion).  This will
ensure consistent behavior despite implementational differences and races.



 In terms of speccing, I'm not sure if we can get away with speccing one
 promise interface or whether we'd need to create one for each type of
 promise.


 On Thu, Feb 18, 2010 at 4:20 PM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 2/18/2010 5:31 AM, Jeremy Orlow wrote:
  On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
  mailto:k...@sitepen.com k...@sitepen.com wrote:
 
  * 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
 
 
  Very interesting.  The general concept seems promising and fairly
  flexible.  You can easily code in a similar style to normal
  async/callback semantics, but it seems like you have a lot more
  flexibility.  I do have a few questions though.
 
  Are there any good examples of these used in the wild that you can
  point me towards?  I used my imagination for prototyping up some
  examples, but it'd be great to see some real examples + be able to
  see the exact semantics used in those implementations.


 Promises are heavily used in the E programming language, the Twisted
 project (python). In JavaScript land, Dojo's Deferred's are an example
 of a form of promises and a number of SSJS projects including Node and
 Narwhal. To see some examples, you can look at the Dojo's docs [1]
 (note that Dojo's spells it addCallback and addErrback instead of
 then, however we are looking to possibly move to the CommonJS
 promise for Dojo 2.0). Here is somewhat random example of module that
 uses Deferred's [2]
 [1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred
 [2]

 http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 3/1/2010 2:52 PM, Jeremy Orlow wrote:
 Thanks for the pointers.  I'm actually pretty sold on the general
 idea of promises, and my intuition is that there won't be a very
 big resource penalty for using an API like this rather than
 callbacks or what's currently specced.  At the same time, it seems
 as though there isn't much of a standard in terms of the precise
 semantics and some of the techniques (such as optionally taking
 callbacks and not returning a promise if they are supplied) seems
 like a decent answer for pure javascript APIs, but maybe not as
 good for IDL and a standard like this.

 Do you guys have any recommendations for the precise semantics we'd
 use, if we used promises in IndexedDB?  To get started, let me list
 what I'd propose and maybe you can offer counter proposals or
 feedback on what would or wouldn't work?


 Each method on a Request interface (the async ones in the spec)
 whose counterpart returns something other than void would instead
 return a Promise.

Asynchronous counterparts to void-returning synchronous functions can
still return promises. The promise would just resolve to undefined,
but it still fulfills the role of indicating when the operation is
complete.

 The promises would only have a then method which would take in an
 onsuccess and onerror callback.  Both are optional.  The onsuccess
 function should take in a single parameter which matches the return
 value of the synchronous counterpart.  The onerror function should
 take in an IDBDatabaseError.  If the callbacks are null, undefined,
 or omitted, they're ignored.  If they're anything else, we should
 probably either raise an exception immediately or ignore them.

Yes.

 If there's an error, all onerror callbacks would be called with the
 IDBDatabaseError.

Yes.

 Exceptions within callbacks would be ignored.

With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,

someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });

Would log the thrown error, effectively giving you a way of catching
the error.

Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me. Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.



 In terms of speccing, I'm not sure if we can get away with speccing
 one promise interface or whether we'd need to create one for each
 type of promise.

Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at least from
the JS perspective, not sure if the extra type constraints in IDL
demand multiple interfaces to model promise's effectively
parameterized generic type form.

- -- 
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/
 
iEYEARECAAYFAkuN6kkACgkQ9VpNnHc4zAwsewCfcqu8L1ZTSU0NUoAL5pG/i+uO
A98An1y2XK2ylsVxVwOxjrsWbn4Jd+y0
=7yq3
-END PGP SIGNATURE-

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

Thanks for the pointers.  I'm actually pretty sold on the general idea of
promises, and my intuition is that there won't be a very big resource
penalty for using an API like this rather than callbacks or what's currently
specced.  At the same time, it seems as though there isn't much of a
standard in terms of the precise semantics and some of the techniques (such
as optionally taking callbacks and not returning a promise if they are
supplied) seems like a decent answer for pure javascript APIs, but maybe not
as good for IDL and a standard like this.

Do you guys have any recommendations for the precise semantics we'd use, if
we used promises in IndexedDB?  To get started, let me list what I'd propose
and maybe you can offer counter proposals or feedback on what would or
wouldn't work?


Each method on a Request interface (the async ones in the spec) whose
counterpart returns something other than void would instead return a
Promise.

The promises would only have a then method which would take in an
onsuccess and onerror callback.  Both are optional.  The onsuccess function
should take in a single parameter which matches the return value of the
synchronous counterpart.  The onerror function should take in an
IDBDatabaseError.  If the callbacks are null, undefined, or omitted, they're
ignored.  If they're anything else, we should probably either raise an
exception immediately or ignore them.

If there's an error, all onerror callbacks would be called with the
IDBDatabaseError.

Exceptions within callbacks would be ignored.


In terms of speccing, I'm not sure if we can get away with speccing one
promise interface or whether we'd need to create one for each type of
promise.


On Thu, Feb 18, 2010 at 4:20 PM, Kris Zyp k...@sitepen.com wrote:

  -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 2/18/2010 5:31 AM, Jeremy Orlow wrote:
  On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
  mailto:k...@sitepen.com k...@sitepen.com wrote:
 
  * 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
 
 
  Very interesting.  The general concept seems promising and fairly
  flexible.  You can easily code in a similar style to normal
  async/callback semantics, but it seems like you have a lot more
  flexibility.  I do have a few questions though.
 
  Are there any good examples of these used in the wild that you can
  point me towards?  I used my imagination for prototyping up some
  examples, but it'd be great to see some real examples + be able to
  see the exact semantics used in those implementations.


 Promises are heavily used in the E programming language, the Twisted
 project (python). In JavaScript land, Dojo's Deferred's are an example
 of a form of promises and a number of SSJS projects including Node and
 Narwhal. To see some examples, you can look at the Dojo's docs [1]
 (note that Dojo's spells it addCallback and addErrback instead of
 then, however we are looking to possibly move to the CommonJS
 promise for Dojo 2.0). Here is somewhat random example of module that
 uses Deferred's [2]
 [1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred
 [2]

 http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc/JsonRest.js



 
  I see that you can supply an error handling callback to .then(), but
  does that only apply to the one operation?  I could easily imagine
  emulating try/catch type semantics and have errors continue down the
  line of .then's until someone handles it.  It might even make sense
  to allow the error handlers to re-raise (i.e. allow to
  bubble) errors so that later routines would get them as well.
 Yes, that's exactly right, errors can

[IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Jeremy Orlow]

On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote:

  * 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


Very interesting.  The general concept seems promising and fairly flexible.
 You can easily code in a similar style to normal async/callback semantics,
but it seems like you have a lot more flexibility.  I do have a few
questions though.

Are there any good examples of these used in the wild that you can point me
towards?  I used my imagination for prototyping up some examples, but it'd
be great to see some real examples + be able to see the exact semantics used
in those implementations.

I see that you can supply an error handling callback to .then(), but does
that only apply to the one operation?  I could easily imagine emulating
try/catch type semantics and have errors continue down the line of .then's
until someone handles it.  It might even make sense to allow the error
handlers to re-raise (i.e. allow to bubble) errors so that later routines
would get them as well.  Maybe you'd even want it to bubble by default?
 What have other implementations done with this stuff?  What is the most
robust and least cumbersome for typical applications?  (And, in te complete
absence of real experience, are there any expert opinions on what might
work?)

Overall this seems fairly promising and not that hard to implement.  Do
others see pitfalls that I'm missing?

J

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Joseph Pecoraro]

On Feb 18, 2010, at 4: 31AM, Jeremy Orlow wrote
 Very interesting.  The general concept seems promising and fairly flexible.  
 You can easily code in a similar style to normal async/callback semantics, 
 but it seems like you have a lot more flexibility.  I do have a few questions 
 though.
 
 Are there any good examples of these used in the wild that you can point me 
 towards?  I used my imagination for prototyping up some examples, but it'd be 
 great to see some real examples + be able to see the exact semantics used in 
 those implementations.

The node.js community has some experience with promises. Here was a
recent discussion they had on promises and alternatives (although
I think it was primarily syntax driven):
http://groups.google.com/group/nodejs/browse_thread/thread/78ad3478317ee19c/625b1d0f013206fa

If you're unfamiliar with node.js [1], it strives to always be
asynchronous and non-blocking. There are a number of database wrapper
modules, nearly all of which should give examples of using promises:
http://wiki.github.com/ry/node/modules#database

- Joe

[1]: http://nodejs.org/

Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 2/18/2010 5:31 AM, Jeremy Orlow wrote:
 On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com
 mailto:k...@sitepen.com wrote:

 * 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


 Very interesting.  The general concept seems promising and fairly
 flexible.  You can easily code in a similar style to normal
 async/callback semantics, but it seems like you have a lot more
 flexibility.  I do have a few questions though.

 Are there any good examples of these used in the wild that you can
 point me towards?  I used my imagination for prototyping up some
 examples, but it'd be great to see some real examples + be able to
 see the exact semantics used in those implementations.

Promises are heavily used in the E programming language, the Twisted
project (python). In JavaScript land, Dojo's Deferred's are an example
of a form of promises and a number of SSJS projects including Node and
Narwhal. To see some examples, you can look at the Dojo's docs [1]
(note that Dojo's spells it addCallback and addErrback instead of
then, however we are looking to possibly move to the CommonJS
promise for Dojo 2.0). Here is somewhat random example of module that
uses Deferred's [2]
[1] http://api.dojotoolkit.org/jsdoc/1.3/dojo.Deferred
[2]
http://download.dojotoolkit.org/release-1.4.1/dojo-release-1.4.1/dojox/rpc/JsonRest.js



 I see that you can supply an error handling callback to .then(), but
 does that only apply to the one operation?  I could easily imagine
 emulating try/catch type semantics and have errors continue down the
 line of .then's until someone handles it.  It might even make sense
 to allow the error handlers to re-raise (i.e. allow to
 bubble) errors so that later routines would get them as well.
Yes, that's exactly right, errors can be raised/thrown and propagate
(when an error handling callback is not provided) to the next promise,
and be caught (with an error handler) just as you have expected from
the analogous propagation of errors across stack frames in JS.

 Maybe you'd even want it to bubble by default?  What have other
 implementations done with this stuff?  What is the most robust and
 least cumbersome for typical applications?  (And, in te complete
 absence of real experience, are there any expert opinions on what
 might work?)

I think it is pretty clear you want propagation, just like with normal
sync errors, it is very handy to have a catch/error handler low down
in the stack to generically handle various errors.
 Overall this seems fairly promising and not that hard to implement.
  Do others see pitfalls that I'm missing?

There are certainly numerous design decisions that can be made with
promises.
* If an error occurs and an error handler is not provided in the
current event turn (note that an event handler can be provided at any
point in the future), should the error be logged somewhere?
* If an callback handler is added to an already fulfilled promise,
should the callback be executed immediately or in the next event turn?
Most JS impls execute immediately, but E suggests otherwise.
* One pitfall that a number of prior implementations have made is in
having callback's return value mutate the current promise instead of
returning the new one, the CommonJS spec makes it clear that then()
should return a new promise that receives the return values from the
callback.

- -- 
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/
 
iEYEARECAAYFAkt9aNIACgkQ9VpNnHc4zAxMBgCfUG0/CVTgV15MBe8uQRDc6RPW

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

[Kris Zyp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 


On 2/1/2010 8:17 PM, Pablo Castro wrote:
 [snip]

 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.


You can't use member access syntax in IE8 and Safari 4 because they
only implement EcmaScript3. But obviously, these aren't the target
versions, the future versions would be the target of this spec. ES5
specifically contextually unreserves keywords, so obj.delete(id) is
perfectly valid syntax for all target browser versions. ES5 predates
Indexed DB API, so it doesn't make any sense to design around an
outdated EcmaScript behavior (also it is still perfectly possible to
set/call the delete property in ES3, you do so with object[delete](id)).

- -- 
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/
 
iEYEARECAAYFAktogZkACgkQ9VpNnHc4zAytzgCeIssVuHKnsYaQ7Nd9Dhm5LxVN
K+EAn32wlsyD17GKDqIPonEKLqt6v9nm
=jTAo
-END PGP SIGNATURE-

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

[Pablo Castro]

A few comments inline marked with [PC].

From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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

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

[Dean Landolt]

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

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

[Kris Zyp]

-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

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-

XQuery WG Comments on Indexed Database API

[John Snelson]

Web Applications Working Group,

The XQuery working group have asked me to submit the following comments 
on their behalf, in review of Indexed Database API (Editor's Draft 26 
January 2010):


1) This document does not seem to have any overlap with the XQuery
specifications themselves.

2) The API specified in this document looks entirely suitable for
implementing an XQuery database on top of, if that was your objective.

John Snelson

--
John Snelson, Oracle Corporationhttp://snelson.org.uk/john
Berkeley DB XML:http://oracle.com/database/berkeley-db/xml
XQilla:  http://xqilla.sourceforge.net

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

[Adrian Bateman]

At Microsoft, we don't believe the spec is quite ready for Last Call. Based on 
our prototyping work, we're preparing some additional feedback that we think is 
more substantive than would be appropriate for Last Call comments. I anticipate 
that we will be able to post this feedback to the working group next Monday 
(25th Jan).

From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Jonas Sicking
Sent: Tuesday, January 19, 2010 9:48 PM
To: Maciej Stachowiak
Cc: Arthur Barstow; public-webapps; Jeremy Orlow
Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
February 2


For what it's worth we are in the same situation at mozilla
On Jan 19, 2010 3:40 PM, Maciej Stachowiak 
m...@apple.commailto:m...@apple.com wrote:

On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote:  On Tue, Jan 19, 2010 at 4:50 
AM, Arthur Barstow...
We at Apple are also in reviewing the spec and would also like additional time 
to review. It doesn't matter that much to us if the review time is before or 
during Last Call, but we definitely can't do a meaningful review by February 2, 
and therefore cannot really sign off by that date on whether the document has 
satisfied relevant technical requirements, is feature-complete, and has all 
issues resolved.

(As far as I can tell the document is less than 4 months old as an Editor's 
Draft and is about 60 pages long, so I hope it is reasonable to ask for some 
reasonable amount of review time.)

Regards,
Maciej

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

[Arthur Barstow]

Nikunj would like to move the Indexed Database API spec to Last Call  
Working Draft (LCWD):


 http://dev.w3.org/2006/webapi/WebSimpleDB/

If you have any comments, please send them to public-webapps@w3.org  
by February 2.


Note the Process Document states the following regarding the  
significance/meaning of a LCWD:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
Purpose: A Working Group's Last Call announcement is a signal that:

* the Working Group believes that it has satisfied its relevant  
technical requirements (e.g., of the charter or requirements  
document) in the Working Draft;


* the Working Group believes that it has satisfied significant  
dependencies with other groups;


* other groups SHOULD review the document to confirm that these  
dependencies have been satisfied. In general, a Last Call  
announcement is also a signal that the Working Group is planning to  
advance the technical report to later maturity levels.

]]

Additionally, a LCWD should be considered feature-complete with all  
issues resolved.


If there are other groups that should be asked for comments, please  
forward this email to them or identify the group(s).


-Regards, Art Barstow

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

[Jeremy Orlow]

On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow art.bars...@nokia.comwrote:

 Nikunj would like to move the Indexed Database API spec to Last Call
 Working Draft (LCWD):

  http://dev.w3.org/2006/webapi/WebSimpleDB/

 If you have any comments, please send them to public-webapps@w3.org by
 February 2.

 Note the Process Document states the following regarding the
 significance/meaning of a LCWD:

 [[
 http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
 Purpose: A Working Group's Last Call announcement is a signal that:

 * the Working Group believes that it has satisfied its relevant technical
 requirements (e.g., of the charter or requirements document) in the Working
 Draft;

 * the Working Group believes that it has satisfied significant dependencies
 with other groups;

 * other groups SHOULD review the document to confirm that these
 dependencies have been satisfied. In general, a Last Call announcement is
 also a signal that the Working Group is planning to advance the technical
 report to later maturity levels.
 ]]

 Additionally, a LCWD should be considered feature-complete with all issues
 resolved.

 If there are other groups that should be asked for comments, please forward
 this email to them or identify the group(s).

 -Regards, Art Barstow


We (Google) support this LC publication.

We would, however, like time to gather meaningful experience with the spec
before the last call review period ends.  We expect we'll have this
experience by the end of May.  Would it be permissible to have a 4 month LC
review period to facilitate this?

Thanks,
Jeremy

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

[Maciej Stachowiak]

On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote:

 On Tue, Jan 19, 2010 at 4:50 AM, Arthur Barstow art.bars...@nokia.com wrote:
 Nikunj would like to move the Indexed Database API spec to Last Call Working 
 Draft (LCWD):
 
  http://dev.w3.org/2006/webapi/WebSimpleDB/
 
 If you have any comments, please send them to public-webapps@w3.org by 
 February 2.
 
 Note the Process Document states the following regarding the 
 significance/meaning of a LCWD:
 
 [[
 http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
 Purpose: A Working Group's Last Call announcement is a signal that:
 
 * the Working Group believes that it has satisfied its relevant technical 
 requirements (e.g., of the charter or requirements document) in the Working 
 Draft;
 
 * the Working Group believes that it has satisfied significant dependencies 
 with other groups;
 
 * other groups SHOULD review the document to confirm that these dependencies 
 have been satisfied. In general, a Last Call announcement is also a signal 
 that the Working Group is planning to advance the technical report to later 
 maturity levels.
 ]]
 
 Additionally, a LCWD should be considered feature-complete with all issues 
 resolved.
 
 If there are other groups that should be asked for comments, please forward 
 this email to them or identify the group(s).
 
 -Regards, Art Barstow
 
 
 We (Google) support this LC publication.
 
 We would, however, like time to gather meaningful experience with the spec 
 before the last call review period ends.  We expect we'll have this 
 experience by the end of May.  Would it be permissible to have a 4 month LC 
 review period to facilitate this?

We at Apple are also in reviewing the spec and would also like additional time 
to review. It doesn't matter that much to us if the review time is before or 
during Last Call, but we definitely can't do a meaningful review by February 2, 
and therefore cannot really sign off by that date on whether the document has 
satisfied relevant technical requirements, is feature-complete, and has all 
issues resolved.

(As far as I can tell the document is less than 4 months old as an Editor's 
Draft and is about 60 pages long, so I hope it is reasonable to ask for some 
reasonable amount of review time.)

Regards,
Maciej

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

[Jonas Sicking]

For what it's worth we are in the same situation at mozilla

On Jan 19, 2010 3:40 PM, Maciej Stachowiak m...@apple.com wrote:

On Jan 19, 2010, at 3:05 PM, Jeremy Orlow wrote:  On Tue, Jan 19, 2010 at
4:50 AM, Arthur Barstow...
We at Apple are also in reviewing the spec and would also like additional
time to review. It doesn't matter that much to us if the review time is
before or during Last Call, but we definitely can't do a meaningful review
by February 2, and therefore cannot really sign off by that date on whether
the document has satisfied relevant technical requirements, is
feature-complete, and has all issues resolved.

(As far as I can tell the document is less than 4 months old as an Editor's
Draft and is about 60 pages long, so I hope it is reasonable to ask for some
reasonable amount of review time.)

Regards,
Maciej

Re: to publish new Working Draft of Indexed Database API; deadline December 21

[Charles McCathieNevile]

On Tue, 22 Dec 2009 03:43:21 +0100, Adrian Bateman  
adria...@microsoft.com wrote:



Microsoft supports publishing a new Working Draft.


As does Opera (sorry, I have been offline)

cheers

Chaaks


On Monday, December 14, 2009 12:54 PM, Arthur Barstow wrote:

This is a Call for Consensus (CfC) to publish a new Working Draft of
the Indexed Database API spec with a new short-name of indexeddb:

  http://dev.w3.org/2006/webapi/WebSimpleDB/

As with all of our CfCs, positive response is preferred and
encouraged and silence will be assumed to be assent. The deadline for
comments is 21 December.

Since the comment period ends after the last day to request a 2009
publication, assuming this CfC is agreed, the new WD will be
published 6 January 2010.

-Regards, Art Barstow


Begin forwarded message:

 From: ext Nikunj R. Mehta nikunj.me...@oracle.com
 Date: December 14, 2009 2:26:22 PM EST
 To: public-webapps WG public-webapps@w3.org
 Subject: Indexed Database API (previously WebSimpleDB) ready for a
 new WD
 Archived-At: http://www.w3.org/mid/981D8DE7-B1F3-4075-ACC6-
 a895c6665...@oracle.com

 Dear Chairs,

 Indexed Database API [1] is ready for a new WD. I have addressed
 various issues reported to the WebApps WG so far. I propose the short
 name indexeddb to replace websimpledb at this time.

 I know of one issue reported by Pablo Castro that is not resolved [2]:
 Usability of asynchronous APIs. This discussion needs its own time and
 more study to improve upon the approach currently in the ED.

 Thanks,
 Nikunj
 http://o-micron.blogspot.com

 [1] http://dev.w3.org/2006/webapi/WebSimpleDB/
 [2] http://www.w3.org/mid/
 f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.m
 icrosoft.com










--
Charles McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: to publish new Working Draft of Indexed Database API; deadline December 21

[Nikunj R. Mehta]

Hi Adrian,

I have published a non-JS version of the same document as the pub- 
ready WD. You can take a look at it:


http://dev.w3.org/2006/webapi/WebSimpleDB/

I hope that works for you.

Nikunj
On Dec 21, 2009, at 6:58 PM, Adrian Bateman wrote:


On Monday, December 21, 2009 6:43 PM, I wrote:

Microsoft supports publishing a new Working Draft.

However, there appears to be a problem with the Respec.js script at
http://dev.w3.org/2006/webapi/WebSimpleDB/.


Apparently, the script takes some time to run (at least when I tried  
it in Firefox) and is incompatible with Internet Explorer. Is it  
possible to capture the result of the script running and publish that?


Thanks,

Adrian.

RE: to publish new Working Draft of Indexed Database API; deadline December 21

[Adrian Bateman]

On Tuesday, December 22, 2009 2:39 PM, Nikunj R. Mehta wrote:
 Hi Adrian,
 
 I have published a non-JS version of the same document as the pub-
 ready WD. You can take a look at it:
 
 http://dev.w3.org/2006/webapi/WebSimpleDB/
 
 I hope that works for you.
 
 Nikunj

Looks good. Thanks Nikunj.

 On Dec 21, 2009, at 6:58 PM, Adrian Bateman wrote:
 
  On Monday, December 21, 2009 6:43 PM, I wrote:
  Microsoft supports publishing a new Working Draft.
 
  However, there appears to be a problem with the Respec.js script at
  http://dev.w3.org/2006/webapi/WebSimpleDB/.
 
  Apparently, the script takes some time to run (at least when I tried
  it in Firefox) and is incompatible with Internet Explorer. Is it
  possible to capture the result of the script running and publish that?
 
  Thanks,
 
  Adrian.
 

RE: to publish new Working Draft of Indexed Database API; deadline December 21

[Adrian Bateman]

Microsoft supports publishing a new Working Draft.

However, there appears to be a problem with the Respec.js script at
http://dev.w3.org/2006/webapi/WebSimpleDB/.


On Monday, December 14, 2009 12:54 PM, Arthur Barstow wrote:
 This is a Call for Consensus (CfC) to publish a new Working Draft of
 the Indexed Database API spec with a new short-name of indexeddb:
 
   http://dev.w3.org/2006/webapi/WebSimpleDB/
 
 As with all of our CfCs, positive response is preferred and
 encouraged and silence will be assumed to be assent. The deadline for
 comments is 21 December.
 
 Since the comment period ends after the last day to request a 2009
 publication, assuming this CfC is agreed, the new WD will be
 published 6 January 2010.
 
 -Regards, Art Barstow
 
 
 Begin forwarded message:
 
  From: ext Nikunj R. Mehta nikunj.me...@oracle.com
  Date: December 14, 2009 2:26:22 PM EST
  To: public-webapps WG public-webapps@w3.org
  Subject: Indexed Database API (previously WebSimpleDB) ready for a
  new WD
  Archived-At: http://www.w3.org/mid/981D8DE7-B1F3-4075-ACC6-
  a895c6665...@oracle.com
 
  Dear Chairs,
 
  Indexed Database API [1] is ready for a new WD. I have addressed
  various issues reported to the WebApps WG so far. I propose the short
  name indexeddb to replace websimpledb at this time.
 
  I know of one issue reported by Pablo Castro that is not resolved [2]:
  Usability of asynchronous APIs. This discussion needs its own time and
  more study to improve upon the approach currently in the ED.
 
  Thanks,
  Nikunj
  http://o-micron.blogspot.com
 
  [1] http://dev.w3.org/2006/webapi/WebSimpleDB/
  [2] http://www.w3.org/mid/
  f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.m
  icrosoft.com
 
 
 
 

RE: to publish new Working Draft of Indexed Database API; deadline December 21

[Adrian Bateman]

On Monday, December 21, 2009 6:43 PM, I wrote:
 Microsoft supports publishing a new Working Draft.
 
 However, there appears to be a problem with the Respec.js script at
 http://dev.w3.org/2006/webapi/WebSimpleDB/.

Apparently, the script takes some time to run (at least when I tried it in 
Firefox) and is incompatible with Internet Explorer. Is it possible to capture 
the result of the script running and publish that?

Thanks,

Adrian.

Indexed Database API (previously WebSimpleDB) ready for a new WD

[Nikunj R. Mehta]

Dear Chairs,

Indexed Database API [1] is ready for a new WD. I have addressed  
various issues reported to the WebApps WG so far. I propose the short  
name indexeddb to replace websimpledb at this time.


I know of one issue reported by Pablo Castro that is not resolved [2]:  
Usability of asynchronous APIs. This discussion needs its own time and  
more study to improve upon the approach currently in the ED.


Thanks,
Nikunj
http://o-micron.blogspot.com

[1] http://dev.w3.org/2006/webapi/WebSimpleDB/
[2] 
http://www.w3.org/mid/f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.microsoft.com

CfC: to publish new Working Draft of Indexed Database API; deadline December 21

[Arthur Barstow]

This is a Call for Consensus (CfC) to publish a new Working Draft of  
the Indexed Database API spec with a new short-name of indexeddb:


 http://dev.w3.org/2006/webapi/WebSimpleDB/

As with all of our CfCs, positive response is preferred and  
encouraged and silence will be assumed to be assent. The deadline for  
comments is 21 December.


Since the comment period ends after the last day to request a 2009  
publication, assuming this CfC is agreed, the new WD will be  
published 6 January 2010.


-Regards, Art Barstow


Begin forwarded message:


From: ext Nikunj R. Mehta nikunj.me...@oracle.com
Date: December 14, 2009 2:26:22 PM EST
To: public-webapps WG public-webapps@w3.org
Subject: Indexed Database API (previously WebSimpleDB) ready for a  
new WD
Archived-At: http://www.w3.org/mid/981D8DE7-B1F3-4075-ACC6- 
a895c6665...@oracle.com


Dear Chairs,

Indexed Database API [1] is ready for a new WD. I have addressed
various issues reported to the WebApps WG so far. I propose the short
name indexeddb to replace websimpledb at this time.

I know of one issue reported by Pablo Castro that is not resolved [2]:
Usability of asynchronous APIs. This discussion needs its own time and
more study to improve upon the approach currently in the ED.

Thanks,
Nikunj
http://o-micron.blogspot.com

[1] http://dev.w3.org/2006/webapi/WebSimpleDB/
[2] http://www.w3.org/mid/ 
f753b2c401114141b426db383c8885e01b9cd...@tk5ex14mbxc126.redmond.corp.m 
icrosoft.com