On 16 Aug 2010, at 21:29, Bernard Traversat wrote:
On 8/16/10 2:34 AM, Rich Tibbett wrote:
On 14/08/2010 03:12, Bernard Traversat wrote:
Should we have a more explicit way to specify and notify users that some
updates may require data conversion and
user data will be converted after the
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10396
Summary: [IndexedDB] LEFT_BOUND and RIGHT_BOUND could be a bit
more clear
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10397
Summary: [IndexedDB] upper and lower bounds would be much
clearer than right/left
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Hi,
I was wondering if there's a list of which major user agents support
(even partially) which APIs?
Best,
Nathan
On 8/19/10 8:07 AM, ext Nathan wrote:
I was wondering if there's a list of which major user agents support
(even partially) which APIs
One source of data is:
http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
If folks would provide implementation data for WebApps' specs, I could
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10400
Summary: [IndexedDB] IDBCursor.continue should return an
IDBRequest
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Sorry, I replied on the bug rather than to the list. Here's what I said:
Hm, I think the wording in the spec is bad, but I believe this bug is invalid.
The way we envisioned this for the async api is that calling continue() always
returns true (to match sync api, but it's really pointless) and
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10402
Summary: [IndexedDB] IDBCursor.remove/update behavior when at
end of range unspecified
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
On Thu, Aug 19, 2010 at 7:22 PM, ben turner bent.mozi...@gmail.com wrote:
Sorry, I replied on the bug rather than to the list. Here's what I said:
Hm, I think the wording in the spec is bad, but I believe this bug is
invalid.
The way we envisioned this for the async api is that calling
We also need to define behavior when any method is called outside of a
cursor callback. I.e.
db.transaction(['foo']).objectStore('foo').openCursor(...).onsuccess =
function(e) {
var cursor = e.result;
if (cursor) {
setTimeout(function() {
cursor.value;
cursor.remove();
On Thu, Aug 19, 2010 at 8:11 PM, Jonas Sicking jo...@sicking.cc wrote:
We also need to define behavior when any method is called outside of a
cursor callback. I.e.
db.transaction(['foo']).objectStore('foo').openCursor(...).onsuccess =
function(e) {
var cursor = e.result;
if (cursor) {
Hi All,
Ben Turner put some comments in the bug, but I'll add a bit here too.
The idea was that cursor.continue() should reuse the same request that
was created when .openCursor was called. That makes using cursors
significantly easier since you just have to register one 'success'
handler,
On Thu, Aug 19, 2010 at 7:06 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Ben Turner put some comments in the bug, but I'll add a bit here too.
The idea was that cursor.continue() should reuse the same request that
was created when .openCursor was called. That makes using cursors
On Thu, Aug 19, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
We also remove the return value from .continue() and make it return
void. It doesn't make sense to return a bool indicating if this was
the last entry or not since we only know that information
asynchronously.
Do you
Moving to on-list since this is more of a discussion...
On Thu, Aug 19, 2010 at 6:36 PM, bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10400
Ben Turner bent.mozi...@gmail.com changed:
What|Removed |Added
15 matches
Mail list logo
