Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

I'm person On Fri, May 17, 2013 at 2:37 PM, Ben Kelly wrote: > Hello all, > > Recently I've been working on a mobile application that makes heavy use of > IndexedDB. In particular, there are times when this app must query a > potentially large, non-consecutive list of keys. Currently (to my >

Re: Collecting real world use cases (Was: Fixing appcache: a proposal to get us started)

I think there are some good use cases for not-quite-offline as well. Sort of a combination of your twitter and wikipedia use cases: Community-content site: Logged-out users have content cached aggressively offline - meaning every page visited should be cached until told otherwise. Intermediate cac

Re: InedxedDB events : misconception?

On Mon, Apr 22, 2013 at 9:56 AM, Michaël Rouges wrote: > > Hum ... thank you for this answer, but ... > > Are you sure there is no possibility that the application is completed > before adding events? > > I find it hard to perceive how it couldn't happen. > Just to close the loop on this concern:

Re: Fixing appcache: a proposal to get us started

> This is a tricky problem indeed. > > The current appcache actually has the behavior that you're advocating, > but that's something that a lot of developers has complained about. In > fact, that's the second biggest complaint that I've heard only > trailing the confusing "master entries" behavior.

Re: IndexedDB, what were the issues? How do we stop it from happening again?

Sorry in advance for the long reply here.. TL;DR is: 1) I still don't think transactions are a requirement 2) I think fixing the platform's motley crew of async apis, and giving developers better control over transaction commits (When you do use them) is probably most important. On Tue, Mar 19, 2

Re: IndexedDB, what were the issues? How do we stop it from happening again?

> transactions - Also should be optional. Vital to complex apps, but totally > > not necessary for many.. there should be a default transaction, like > > db.objectStore("foo").get("bar") > > I disagree. This would have made it too trivial to create pages that > have race conditions. I.e. people w

Re: IndexedDB, what were the issues? How do we stop it from happening again?

bjectStores is an abstraction that could be implemented on a single keystore. To be fair, implementing transactions against a transactionless keystore would not be *performant*, but thats a separate issue. Now that we have transactions and versions, I wouldn't eliminate them from IDB by any means, bu

Re: IndexedDB, what were the issues? How do we stop it from happening again?

My primary takeaway from both working on IDB and working with IDB for some demo apps is that IDB has just the right amount of complexity for really large, robust database use.. but for a "welcome to noSQL in the browser" it is way too complicated. Specifically: 1. *versioning* - The reason thi

Re: IndexedDB: undefined parameters

On Tue, Oct 9, 2012 at 11:37 AM, Alec Flett wrote: > > > On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky wrote: > >> On 10/9/12 1:52 PM, Joshua Bell wrote: >> >>> The IDB spec does not have [TreatUndefinedAs=Missing] specified on >>> openCursor()&#x

Re: IndexedDB: undefined parameters

On Tue, Oct 9, 2012 at 11:12 AM, Boris Zbarsky wrote: > On 10/9/12 1:52 PM, Joshua Bell wrote: > >> The IDB spec does not have [TreatUndefinedAs=Missing] specified on >> openCursor()'s arguments (or anywhere else), so I believe Chrome's >> behavior here is correct. >> > > It looks correct as the

Re: IndexedDB: ambiguity around createIndex order-of-operations

On Mon, Aug 13, 2012 at 12:23 PM, Jonas Sicking wrote: > > I think the two puts need to succeed. Implementation would be very > complex and suboptimal otherwise. You need to know that there's a > pending index-create operation and wait with firing success values for > any requests until both all

IndexedDB: ambiguity around createIndex order-of-operations

jsbell and I have been discussing a possible ambiguity in the IndexedDB spec w.r.t. error handling around createIndex calls. In particular, createIndex() is supposed to behave somewhat synchronously in that calling: > the implementation *must* create a > newindex

Re: IndexedDB and RegEx search

> > This is somewhat similar to [1] and something we decided was > > out-of-scope for v1. But for v2 I definitely think we should look at > > mechanisms for using JS code to filter/sort/index data in such a way > > that the JS code is run on the IO thread. > > > > [1] https://www.w3.org/Bugs/Public

Re: IndexedDB and RegEx search

FWIW it's fairly hard to for a database to index arbitrary content for regexes, to the point where it's going to be hard to do MUCH better than simply filtering based on regex. Out of curiosity, would the "free text search" feature on that wiki page that Arthur provided meet your needs? it's more a

Re: [UndoManager] Re-introduce DOMTransaction interface?

[trying again with the right e-mail, sorry for the dupes...] On Thu, Jul 12, 2012 at 12:38 PM, Jonas Sicking wrote: > On Thu, Jul 12, 2012 at 2:07 AM, Yuval Sadan > wrote: > >> I think we need to realize that a lot of the APIs that have been > >> designed in the past aren't terribly good APIs.

Re: [UndoManager] Re-introduce DOMTransaction interface?

On Thu, Jul 12, 2012 at 12:38 PM, Jonas Sicking wrote: > On Thu, Jul 12, 2012 at 2:07 AM, Yuval Sadan > wrote: > >> I think we need to realize that a lot of the APIs that have been > >> designed in the past aren't terribly good APIs. > > > > The IndexedDB API is rather new, and the manner in whi

Re: [webcomponents] HTML Parsing and the element

On Thu, Jun 7, 2012 at 2:45 AM, Henri Sivonen wrote: > On Wed, Jun 6, 2012 at 7:13 PM, Tab Atkins Jr. > wrote: > > A call like "document.querySelectorAll('p')" doesn't *want* to get the > > inside the template. > > I think it's backwards to assume that querySelectorAll() works a > particular wa

IndexedDB: use of TypeError

So I didn't start working on/implementing indexedDB until after this message went out: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0958.html So I haven't had to face the full implications of using TypeError until this week. I'd like to (hopefully not too late) voice my oppositi

Re: IndexedDB: ambiguity around IDBTransaction.error

Done. https://www.w3.org/Bugs/Public/show_bug.cgi?id=17236 On Tue, May 29, 2012 at 2:31 AM, Jonas Sicking wrote: > On Fri, May 25, 2012 at 1:16 PM, Alec Flett wrote: > > I have found what feels like an ambiguity in the spec around > > IDBTransaction..error and when it is availa

IndexedDB: ambiguity around IDBTransaction.error

I have found what feels like an ambiguity in the spec around IDBTransaction.error and when it is available. In particular, the spec says: > When the done flag is > true, getting this property *must* return the error of the request that > caused t