On Friday, January 4, 2013 4:27 AM, Arthur Barstow wrote:
On 12/10/12 5:12 PM, ext Joshua Bell wrote:
Given the state of the open issues, I'm content to wait until an
editor has bandwidth. I believe there is consensus on the resolution
of the issues and implementations are already
/Archives/Public/public-webapps/2010OctDec/0599.htm
l
Israel Hilerio said:
Since we're seeing this behavior in both browsers (FF and Canary) we
wanted to validate that this is not by design.
It would bet several pennies its by design, because the spec needs
more framework to explain this than
We noticed there is consistent behavior between FF v.15.0.1 and Chrome
v.24.0.1284.0 canary that we believe is a bug when dealing with both
'prevunique' and 'nextunique'. Below is what we're seeing using the following
site http://jsbin.com/iyobis/10/edit
For the following data set (keypath =
We approve too!
Israel
On Tuesday, May 08, 2012 9:45 AM, Jonas Sicking wrote:
I approve!!
/ Jonas
On Tue, May 8, 2012 at 8:29 AM, Arthur Barstow art.bars...@nokia.com
wrote:
As discussed during last week's f2f meeting [Mins], IDB bug 14404 was
the last remaining bug blocking a LCWD
On Thursday, May 03, 2012 3:30 PM, Jonas Sicking wrote:
On Thu, May 3, 2012 at 1:30 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
The issue of bug 14404 came up at the WebApps face-to-face today. I
believe it's now the only remaining non-editorial bug. Since we've
tried to fix this
The approach you described makes sense to us.
Thanks for clarifying.
Israel
On Saturday, March 03, 2012 5:07 PM, Jonas Sicking wrote:
On Fri, Mar 2, 2012 at 8:49 PM, Israel Hilerio isra...@microsoft.com wrote:
We would like some clarification on this scenario. When you say that
FF
On Friday, March 02, 2012 7:27 AM, Jonas Sicking wrote:
On Fri, Mar 2, 2012 at 4:35 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
While editing the spec just now I came across something that I didn't
quite understand. In section 4.8 versionchange transaction steps
step 9 says:
We would like some clarification on this scenario. When you say that FF will
result on 1 index entry for each index that implies that the duplicates are
automatically removed. That implies that the multiEntry flag doesn't take
unique into consideration. Is this correct?
There seems to be
We agree with FF's implementation. It seems to match the current sparse index
concept where values that can't be indexed are automatically ignored. However,
this doesn't prevent them from being added.
Israel
On Friday, March 02, 2012 8:59 AM, Joshua Bell wrote:
On Thu, Mar 1, 2012 at 8:20 PM,
, that doesn't
seem to match the spec.
On Fri, Mar 2, 2012 at 11:52 AM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
We agree with FF's implementation. It seems to match the current sparse index
concept where values that can't be indexed are automatically ignored. However
I’ve created a bug to track this issue:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16211
Israel
On Friday, March 02, 2012 4:39 PM, Odin Hørthe Omdal wrote:
From: Israel Hilerio isra...@microsoft.commailto:isra...@microsoft.com
Unfortunately, we didn’t update the spec to reflect
I'm okay with setting the value of the objectStoresNames to empty instead of
null.
Israel
On Friday, March 02, 2012 4:46 PM, Odin Hørthe Omdal wrote:
I concur with Israel, plus David's question about nullness as opposed to
emptiness.
--
Odin, Opera
We need to define in the spec what should happen if a developers defines an
invalid mode or direction. Do we throw a TypeError Exception or revert to
defauls?
FF seems to allow this behavior and reverts back to a readOnly transaction mode
and a direction of next, respectively:
*
IE is not planning on implementing the IDBSync APIs for IE10 and we proposed to
mark them “At Risk” on the current spec.
Israel
On Tuesday, February 28, 2012 11:17 AM, Kyle Huey wrote:
On Tue, Feb 28, 2012 at 11:13 AM, Joshua Bell
jsb...@chromium.orgmailto:jsb...@chromium.org wrote:
Are there
wrote:
On Sat, 25 Feb 2012 00:34:40 +0100, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com
wrote:
We have several internal and external teams implementing solutions on
IndexedDB for IE10 and Win8. They are looking for a finalized spec sooner
than later to ensure the stability
I'm not sure we should include this in the IDB spec. The reason is that I
would expect every browser to provide different guarantees based on their
internals. In our case after the Javascript engine finishes its processing,
the server starts its processing and once started the server started
being opened, we
should throw a InvalidStateError.
Would this be enough?
Israel
On Thursday, January 26, 2012 9:26 AM, Joshua Bell wrote:
On Wed, Jan 25, 2012 at 11:32 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
On Wed, Jan 25, 2012 at 5:23 PM, Israel Hilerio
isra
On Wednesday, January 25, 2012 1:47 AM, Jonas Sicking wrote:
On Tue, Jan 24, 2012 at 12:07 PM, Israel Hilerio
isra...@microsoft.com
wrote:
On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio
isra...@microsoft.com
wrote
On Wednesday, January 25, 2012 12:25 PM, Jonas Sicking wrote:
Hi All,
Joshua reminded me of another thing which is undefined in the specification,
which is key generation. Here's the details of how we do it in Firefox:
The key generator for each objectStore starts at 1 and is increased by
Should we allow the creation of READ_ONLY or READ_WRITE transactions inside the
oncomplete event handler of a VERSION_CHANGE transaction?
IE allows this behavior today. However, we noticed that FF's nightly doesn't.
In either case, we should define this behavior in the spec.
Israel
On Wednesday, January 25, 2012 4:26 PM, Jonas Sicking wrote:
On Wed, Jan 25, 2012 at 3:40 PM, Israel Hilerio isra...@microsoft.com
wrote:
Should we allow the creation of READ_ONLY or READ_WRITE transactions
inside the oncomplete event handler of a VERSION_CHANGE transaction?
IE allows
On Monday, January 23, 2012 8:22 PM, Jonas Sicking wrote:
On Mon, Jan 23, 2012 at 5:17 PM, Joshua Bell jsb...@chromium.org wrote:
On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio
isra...@microsoft.com
wrote:
In looking at the count method in IDBObjectStore and IDBIndex we
noticed
On Tuesday, January 24, 2012 12:12 PM, Jonas Sicking wrote:
On Tue, Jan 24, 2012 at 10:08 AM, Israel Hilerio isra...@microsoft.com
wrote:
In addition, the index method in IDBObjectStore uses
InvalidStateError to convey two different meanings: the object has
been removed or deleted
On Tuesday, January 24, 2012 11:38 AM, Jonas Sicking wrote:
On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jan 23, 2012 at 5:34 PM, Joshua Bell jsb...@chromium.org
wrote:
There's
In looking at the count method in IDBObjectStore and IDBIndex we noticed that
its signature doesn't throw a TransactionInactiveError when the transaction
being used is inactive. We would like to add this to the spec.
In addition, the index method in IDBObjectStore uses InvalidStateError to
like to know how we
explain it to developers.
Thanks,
Israel
On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote:
Based on our retesting of Aurora and Canary, this is the behavior we're seeing:
When a null or undefined keyPath is provided to the createObjectStore API, you
can add
Of Joshua Bell
Sent: Friday, January 20, 2012 10:48 AM
To: Israel Hilerio
Cc: Odin Hørthe Omdal; Jonas Sicking (jo...@sicking.cc); ben turner
(bent.mozi...@gmail.com); Adam Herchenroether; David Sheldon;
public-webapps@w3.org
Subject: Re: [indexeddb] Do we need to support keyPaths with an empty
On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
Given the changes that Jonas made to the spec, on which other scenarios do we
expect developers to specify a keyPath with an empty string (i.e. keyPath =
)?
Do we still need to support this or can we just throw if this takes place. I
of null,
undefined, or empty string will provide a FailFast API.
What do you think?
Israel
On Wednesday, January 18, 2012 12:08 PM Joshua Bell wrote:
On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
On Friday, January 13, 2012 1:33 PM, Israel
On Wednesday, January 18, 2012 1:27 PM, ben turner wrote:
On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com
wrote:
We did some testing in FF and Chrome and found different behaviors:
Hi Israel,
Which version of Firefox did you test with?
Thanks,
Ben
We tested
On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote:
On Wed, Jan 18, 2012 at 1:51 PM, ben turner
bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote:
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
We tested on Firefox 8.0.1
Ah
We updated Section 3.1.3 with examples to capture the behavior you are seeing
in IE. Based on this section, if the attribute doesn't exists and there is an
autogen is set to true the attribute is added to the structure and can be used
to access the generated value. The use case for this is to
Great! I will work with Eliot to unify the language and update the spec.
Israel
On Wednesday, January 11, 2012 3:45 PM, Joshua Bell wrote:
On Wed, Jan 11, 2012 at 3:17 PM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
We updated Section 3.1.3 with examples to capture
On December 15, 2011 10:20 PM, Jonas Sicking wrote:
On Thu, Dec 15, 2011 at 12:54 PM, Joshua Bell jsb...@chromium.org
wrote:
Is there any particular reason why IDBTransaction.objectStore() and
IDBObjectStore.index() should be usable (i.e. return values vs. raise
exceptions) after the
Sounds good! I've updated the bug to reflect this decision.
Israel
On Friday, December 16, 2011 3:37 PM, Joshua Bell wrote:
On Fri, Dec 16, 2011 at 3:30 PM, Jonas Sicking
jo...@sicking.ccmailto:jo...@sicking.cc wrote:
On Fri, Dec 16, 2011 at 2:41 PM, Israel Hilerio
isra
On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote:
On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio isra...@microsoft.com
wrote:
Jonas,
Since you believe we should keep the values of version as a non-nullable
long long, what should the value of version be during the first run
On Saturday, December 03, 2011 9:28 PM, Jonas Sicking wrote:
Subject: Re: [indexeddb] error value of open request after aborting
VERSION_CHANGE transaction inside an onupgradeneeded handler
On Thu, Dec 1, 2011 at 7:16 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Tuesday, November 22
On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote:
On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote:
On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio
isra...@microsoft.com
wrote:
Jonas
On Wednesday, December 07, 2011 3:45 PM, Jonas Sicking wrote:
On Wed, Dec 7, 2011 at 3:15 PM, Israel Hilerio isra...@microsoft.com wrote:
On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote:
On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Saturday
On Wednesday, November 30, 2011 6:30 PM, Jonas Sicking wrote:
On Wed, Nov 30, 2011 at 6:22 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Nov 30, 2011 at 6:11 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote:
On Wed, Nov
Jonas,
Since you believe we should keep the values of version as a non-nullable long
long, what should the value of version be during the first run/creation if the
transaction is aborted? Should it be 0 (I don't believe we want version to be a
negative number)?
Israel
On Tuesday, November 22, 2011 5:30 PM, Israel Hilerio wrote:
Subject: [indexeddb] error value of open request after aborting VERSION_CHANGE
transaction inside an onupgradeneeded handler
What should be the value of the error attribute on the open request after a
VERSION_CHANGE transaction
On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote:
On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell jsb...@chromium.org wrote:
Should the parameter used in IDBObjectStore.createIndex() and the
property on IDBIndex be spelled multientry (as it is in the spec
currently), or multiEntry
What should be the value of the error attribute on the open request after a
VERSION_CHANGE transaction is aborted? We're thinking it should be AbortError
independent of whether the transaction is aborted programmatically or due to a
system failure.
Do you guys agree?
Israel
On Tuesday, November 15, 2011 4:33 PM, Jonas Sicking wrote:
On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote:
Hmm.. good point. Looking at the documentation for the built-in
types, there are
On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote:
On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@microsoft.com wrote:
In section 4.7 Steps for extracting a key from a value using a key path
step #4 it states that:
* If object does not have an attribute named attribute, then skip
In section 4.7 Steps for extracting a key from a value using a key path step
#4 it states that:
* If object does not have an attribute named attribute, then skip the rest of
these steps and no value is returned.
We want to verify that the attribute lookup is taking place on the immediate
On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote:
On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio isra...@microsoft.com wrote:
On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
The firing of error events on the transaction should only be of two types:
propagation error events
:
On Tue, Nov 8, 2011 at 4:54 PM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
On Tuesday, November 08, 2011 2:09 PM, David Grogan wrote:
On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio
isra...@microsoft.commailto:isra...@microsoft.com wrote:
On Friday, October 14, 2011 2:33
On Sunday, November 06, 2011 4:14 PM, Jonas Sicking wrote:
On Fri, Oct 28, 2011 at 9:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 28, 2011 at 9:29 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote:
On Thu, Oct 27, 2011
IE is okay with removing this from the spec.
Israel
On Monday, October 31, 2011 5:06 PM, Joshua Bell wrote:
From: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell
Sent: Monday, October 31, 2011 5:06 PM
To: Webapps WG
Subject: Re: [IndexedDB] Throwing when *creating* a
On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote:
On Thu, Oct 27, 2011 at 9:33 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, October 26, 2011 6:38 PM, Jonas Sicking wrote:
On Wed, Oct 26, 2011 at 11:31 AM, Israel Hilerio
isra...@microsoft.com
wrote
Forgot some things!
On Thursday, October 27, 2011 6:00 PM, Jonas Sicking wrote:
On Thu, Oct 27, 2011 at 9:33 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, October 26, 2011 6:38 PM, Jonas Sicking wrote:
On Wed, Oct 26, 2011 at 11:31 AM, Israel Hilerio
isra...@microsoft.com
On Wednesday, October 26, 2011 10:23 PM, Jonas Sicking wrote:
On Wed, Oct 26, 2011 at 11:41 AM, Israel Hilerio isra...@microsoft.com
wrote:
Based on the feedback from Jonas, Cameron, and Anne, we updated the
exception and error model in the IndexedDB spec [1]. Now, we match the
DOM Level 4
On Wednesday, October 26, 2011 9:35 AM, Joshua Bell wrote:
On Tue, Oct 25, 2011 at 4:50 PM, Israel Hilerio isra...@microsoft.com wrote:
On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote:
While I was there it did occur to me that the fact that the .delete
function returns (through
Based on the feedback from Jonas, Cameron, and Anne, we updated the exception
and error model in the IndexedDB spec [1]. Now, we match the DOM Level 4
events and error models.
The IDBDatabaseException interface was replaced with DOMException. The const
error codes were replace with error
On Friday, October 14, 2011 2:33 PM, Jonas Sicking wrote:
On Thu, Oct 13, 2011 at 10:57 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote:
On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Tuesday
On Monday, October 17, 2011 10:03 PM, Jonas Sicking wrote:
Hi All,
Currently the spec is somewhat inconsistent in how it deals with having an
index on a property, and then inserting an object in an object store which is
either missing that property, or has the property but with a value which
On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote:
On Mon, Oct 24, 2011 at 11:28 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote:
Currently
On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote:
Currently IDBObjectStore.count/get/openCursor and
IDBIndex.count/get/openCursor/openKeyCursor all take a key or a KeyRange.
However IDBObjectStore.delete only accepts keys. We should fix this to allow
.delete to accept a KeyRange as
On Friday, October 14, 2011 6:42 PM, Jonas Sicking wrote:
On Fri, Oct 14, 2011 at 1:51 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
Hi All,
There is one edge case
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
On Monday, October 17, 2011 9:14 PM, Cameron McCormack wrote:
On 17/10/11 7:19 PM, Jonas Sicking wrote:
I sort of like the short-cut since it seems like a very common case
for web developers to want to create a transaction which only uses a
single objectStore.
But I agree it's not a
On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
Hi All,
There is one edge case regarding transaction scheduling that we'd like
to get clarified.
As the spec is written, it's clear what the following code should do
On Monday, October 10, 2011 10:15 AM, Israel Hilerio wrote:
On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote:
On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio
isra...@microsoft.com
wrote:
On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
Hi All,
In both
On Friday, October 14, 2011 2:43 PM, Jonas Sicking wrote:
On Fri, Oct 14, 2011 at 2:27 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Monday, October 10, 2011 10:15 AM, Israel Hilerio wrote:
On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote:
On Fri, Oct 7, 2011 at 11:51 AM
On Friday, October 14, 2011 3:57 PM, Jonas Sicking wrote:
On Fri, Oct 14, 2011 at 2:57 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Friday, October 14, 2011 2:43 PM, Jonas Sicking wrote:
On Fri, Oct 14, 2011 at 2:27 PM, Israel Hilerio
isra...@microsoft.com
wrote:
On Monday
On Monday, October 10, 2011 10:10 PM, Jonas Sicking wrote:
On Thu, Oct 6, 2011 at 3:30 PM, Israel Hilerio isra...@microsoft.com wrote:
On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 12, 2011 at 2
On Thursday, October 13, 2011 12:15 AM, Jonas Sicking wrote:
On Wednesday, October 12, 2011, Israel Hilerio isra...@microsoft.com wrote:
On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio isra...@microsoft.com
wrote:
If a db connection
If a db connection is closed inside the onupgradeneeded handler, section 4.1
step #8 states that we should return an ABORT_ERR and abort steps. This implies
that the transaction should fail. Since today, the db is closed after all
requests have been processed, we don't see the reason why we
On Wednesday, October 12, 2011 4:21 PM, Jonas Sicking wrote:
On Wed, Oct 12, 2011 at 4:06 PM, Israel Hilerio isra...@microsoft.com
wrote:
If a db connection is closed inside the onupgradeneeded handler, section 4.1
step #8 states that we should return an ABORT_ERR and abort steps
On Monday, October 10, 2011 9:46 AM, Jonas Sicking wrote:
On Fri, Oct 7, 2011 at 11:51 AM, Israel Hilerio isra...@microsoft.com
wrote:
On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
Hi All,
In both the Firefox and the Chrome implementation you can pass an
empty array
On Monday, October 03, 2011 10:04 AM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 9:30 AM, Joshua Bell jsb...@chromium.org wrote:
As we're implementing IDBFactory.cmp in WebKit we noticed that the
ordering sense is reversed compared to C's strcmp/memcmp, Perl's
cmp/= operators, etc.
As
On Thursday, October 06, 2011 5:44 PM, Jonas Sicking wrote:
Hi All,
In both the Firefox and the Chrome implementation you can pass an empty
array to IDBDatabase.transaction in order to create a transaction which has
a scope that covers all objectStores in the database. I.e. you can do
On Monday, October 03, 2011 7:31 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 5:36 PM, Israel Hilerio isra...@microsoft.com wrote:
Jonas,
We're removing error code values as part of the new exception type
model.
This will impact the IDBRequest.errorCode property. I believe we want
On Monday, October 03, 2011 7:18 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 4:21 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
For several of these I think we can reuse existing DOMExceptions.
Here's how I'd map
On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
Hi All,
There is one edge case regarding transaction scheduling that we'd like to get
clarified.
As the spec is written, it's clear what the following code should do:
trans1 = db.transaction([foo], IDBTransaction.READ_WRITE);
On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio
isra...@microsoft.com
wrote:
Based on previous conversations, it seems we've agreed
On Thursday, September 29, 2011 12:04 AM, Jonas Sicking wrote:
For several of these I think we can reuse existing DOMExceptions.
Here's how I'd map the exceptions which are currently in the IndexedDB
spec:
UNKNOWN_ERR
Mint a new UnknownError. Alternatively we could simply throw an
Jonas,
We're removing error code values as part of the new exception type model. This
will impact the IDBRequest.errorCode property. I believe we want to rename
this property to errorName and change its type to DOMString in order to match
the new Exception type model name. This change will
On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:54:50 +0200, Israel Hilerio isra...@microsoft.com
wrote:
Microsoft believes that the following text closer reflects the intent
on the WebIDL spec:
* Throws a DOMException of type VersionError.
(vs
On Tuesday, September 27, 2011 1:11 AM, Anne van Kesteren wrote:
On Tue, 27 Sep 2011 02:40:29 +0200, Israel Hilerio isra...@microsoft.com
wrote:
Like Cameron says in the link above and based on the WebIDL
description, it seems we want the IndexedDB text to say, for example:
Throws
On Tuesday, September 27, 2011 5:40 PM, Jonas Sicking wrote:
On Tue, Sep 27, 2011 at 2:41 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio
isra...@microsoft.com
wrote
On Wednesday, September 21, 2011 7:11 PM, Jonas Sicking wrote:
On Mon, Sep 12, 2011 at 1:56 PM, Israel Hilerio isra...@microsoft.com
wrote:
On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
Hi Everyone,
I finally got around to updating the IndexedDB spec to the new version
API
On Monday, September 26, 2011 2:36 AM Anne van Kesteren wrote:
On Mon, 26 Sep 2011 09:31:36 +0200, Anne van Kesteren
ann...@opera.com
wrote:
On Fri, 23 Sep 2011 00:52:39 +0200, Israel Hilerio
isra...@microsoft.com wrote:
This is our understanding on how the spec needs to change to support
Jonas,
This is our understanding on how the spec needs to change to support the new
WebIDL exception handling model. We would start by removing all of the
constants from IDBDatabaseException. After that, the only thing left would be
message. Do we still need to have this class definition?
Jonas,
This is our interpretation of how we see incorporating the new Event
constructor model defined in DOM 4.
[Constructor(DOMString type, optional IDBVersionChangeEventInit
IDBVersionChangeEventInitDict)]
interface IDBVersionChangeEvent : Event {
readonly attribute DOMString oldVersion;
On Wednesday, September 21, 2011 2:50 PM, Jonas Sicking wrote:
On Wed, Sep 21, 2011 at 11:58 AM, Israel Hilerio isra...@microsoft.com
wrote:
Jonas,
This is our interpretation of how we see incorporating the new Event
constructor model defined in DOM 4.
[Constructor(DOMString type
On Tuesday, September 13, 2011 6:27 PM, Adrian Bateman wrote:
Today we shipped Microsoft Internet Explorer 10 Platform Preview 3 as part of
the Windows 8 Developer Preview. Alongside this release, we have submitted
interop tests for several WebApps specs for review by the working group:
On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
Hi Everyone,
I finally got around to updating the IndexedDB spec to the new version API!
Definitely a non-trivial change, so I'd love for people to have a look at it
to
see if I messed anything up.
I decided to go with the name
On Friday, September 02, 2011 3:33 AM, Hans Wennborg wrote:
-Original Message-
From: Hans Wennborg [mailto:hwennb...@google.com]
Sent: Friday, September 02, 2011 3:33 AM
To: Israel Hilerio
Cc: public-webapps@w3.org; Jim Wordelman; Dany Joly; Adam
Herchenroether; Victor Ngo
Subject
On Monday, September 12, 2011 1:56 PM, Israel Hilerio wrote:
On Sunday, September 04, 2011 3:33 AM, Jonas Sicking wrote:
Hi Everyone,
I finally got around to updating the IndexedDB spec to the new version API!
Definitely a non-trivial change, so I'd love for people to have a look
Based on previous conversations, it seems we've agreed that there are
situations in which a transaction could failed independent of explicit requests
(i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be represented as an
implicit request that is being triggered by a transaction. We
Thanks for the feedback. Answers inline.
Israel
On Tuesday, August 30, 2011 9:10 AM, Hans Wennborg wrote:
On Sat, Aug 27, 2011 at 1:00 AM, Israel Hilerio isra...@microsoft.com
wrote:
We looked at the spec to see what it would take to be able to support
multi-column keys on primary keys
Eliot and I went through the spec and identified the various issues stated in
it. Below is our opinion on each of the open issues based on our understanding
of the text. Based on this, there doesn't seem to be anything major that is
blocking our ability to successfully move this spec to Last
support both
single and array values. For example,
---When retrieving the record of a single key index they do this:
var request = index.get(Israel Hilerio);
request.onsuccess = function (evt) { var record = this.result; }
---When retrieving the record of a compound key index
On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote:
On Monday, August 15, 2011, Shawn Wilsher m...@shawnwilsher.com wrote:
On 8/15/2011 3:31 PM, Israel Hilerio wrote:
When the db is doing a commit after processing all records on the
transaction, if for some reason it fails, should
On Thursday, August 04, 2011 11:02 AM, Jonas Sicking wrote:
On Aug 4, 2011 12:28 AM, Joran Greef jo...@ronomon.com wrote:
On 03 Aug 2011, at 7:33 PM, Jonas Sicking wrote:
Note that reads are also blocked if the long-running transaction is a
READ_WRITE transaction.
Is it
On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote:
On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking jo...@sicking.cc wrote:
Yup. Though I think WebIDL will take care of the handling for when the
author specifies a negative value. I.e. WebIDL will specify what
exception to throw, so we
1 - 100 of 184 matches
Mail list logo
