On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow jor...@chromium.org
wrote:
What's the current thinking in terms of events that we're firing? I
On Mon, Feb 14, 2011 at 11:15 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 14, 2011 at 7:53 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 14, 2011 at 7:36 PM, David Grogan dgro...@chromium.org
wrote:
On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow jor...@chromium.org
We (chrome) are still having internal discussions about evictable vs
non-evictable storage; we're on board with worrying about this in v2.
On Tue, May 31, 2011 at 5:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 31, 2011 at 3:46 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
We
On Tue, Aug 16, 2011 at 10:52 AM, Israel Hilerio isra...@microsoft.comwrote:
On Thursday, August 04, 2011 11:02 AM, Jonas Sicking wrote:
[snip]
I'd be open to allowing read transactions which are started after a
write transaction to see the before-write database contents. Would
On Tue, Oct 4, 2011 at 3:01 AM, Jonas Sicking jo...@sicking.cc 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 that there are
On Wed, Oct 26, 2011 at 4:36 PM, Israel Hilerio isra...@microsoft.comwrote:
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,
On Tue, Nov 8, 2011 at 4:54 PM, Israel Hilerio isra...@microsoft.comwrote:
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
On Fri, Mar 2, 2012 at 10:33 AM, Israel Hilerio isra...@microsoft.comwrote:
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
On Mon, Jul 23, 2012 at 11:49 AM, Odin Hørthe Omdal odi...@opera.comwrote:
There are some open issues in the spec that has been there a long time.
They deal with opening and deleting database.
http://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/**
On Thu, Sep 27, 2012 at 9:31 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Sep 27, 2012 at 6:47 AM, João Eiras jo...@opera.com wrote:
http://odinho.html5.org/IndexedDB/spec/Overview.html
Like I said, I think it's too late to make such a big change. I
believe it's much too
On Mon, Feb 11, 2013 at 2:55 PM, Kyle Huey m...@kylehuey.com wrote:
On Mon, Feb 11, 2013 at 10:40 PM, David Grogan dgro...@chromium.orgwrote:
When chrome opens an IDB database, it attempts to detect corruption. If
the database appears to have been corrupted, either via software bug
:
On Tue, Feb 12, 2013 at 1:49 PM, David Grogan dgro...@chromium.orgwrote:
I think the answer to that question impacts how we design this.
I'm assuming you mean because a surgical recovery could leave the version
intact and make a new property on the upgradeneeded event inaccessible? In
that case
On Thu, May 9, 2013 at 4:01 PM, David Grogan dgro...@chromium.org wrote:
jsbell pointed out an annoyance with this approach. If we delete the
entire backing store while opening a database, we can alert the page that
that particular database was lost via the mechanism discussed in this
thread
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370 to track this.
On Thu, May 9, 2013 at 6:01 PM, Kyle Huey m...@kylehuey.com wrote:
On Thu, May 9, 2013 at 4:09 PM, David Grogan dgro...@chromium.org wrote:
On Thu, May 9, 2013 at 4:01 PM, David Grogan dgro...@chromium.orgwrote
As discussed in [thread] we implemented a dataLoss field on the
upgradeneeded event, tracked in [bug]. Following developer feedback on the
implementation in Chrome, we'd like to add a complementary dataLossMessage
field. The combination would act similarly to DOMException/DOMError's name
and
15 matches
Mail list logo
