- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 31 Mar 2011 10:41:30 -0700
- To: Joran Greef <joran@ronomon.com>
- Cc: public-webapps@w3.org
On Thu, Mar 31, 2011 at 1:32 AM, Joran Greef <joran@ronomon.com> wrote: > On 31 Mar 2011, at 9:53 AM, Jonas Sicking wrote: > >> I previously have asked for a detailed proposal, but so far you have >> not supplied one but instead keep referring to other unnamed database >> APIs. > > I have already provided an adequate interface proposal for putObject and deleteObject. That is hardly a comprehensive proposal, but rather just one small part of it. I do really think the idea of not having the implementation keep track of the set of indexes for a objectStore is a really interesting one. As is the idea of not even having a set set of objectStores. However, there are several problems that needs to be solved. In particular how do you deal with collations? I.e. we have concluded that there are important use cases which require using different collations for different indexes and objectStores. Even for different indexes attached to the same objectStore. Additionally, if we're getting rid of setVersion, how do we expect pages dealing with the (application managed) schema changing while the page has a connection open to the database? So pretty please, with sugar on top, please come up with a proposal for the full API rather than bits and pieces. And I should mention that I have as an absolute requirement that you should be able to specify collation by simply saying that you want to use "en-US" or "sv-SV" sorting. Using callbacks or other means is ok *in addition to this*, but callback mechanisms tend to be a lot more complex since they have to deal with the callback doing all sorts of evil things such as returning inconsistent results (think "return Math.random()"), or simply do evil things like navigate the current page, deleting the database, or modifying the record that is in the process of being stored. / Jonas
Received on Thursday, 31 March 2011 17:42:33 UTC