\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
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
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
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
[ 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
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
-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
[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
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
, 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
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
! 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
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
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
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
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
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
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
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
.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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
-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:
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:
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
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
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
-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
-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
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
-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
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 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
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
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
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
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
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
-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
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
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
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
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
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
-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
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
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
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
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
-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
. 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
-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
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
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
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.
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
-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
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
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
. 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
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
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
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
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
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
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
) 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
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:
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.
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
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
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
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
1 - 100 of 102 matches
Mail list logo
