On Mon, Aug 16, 2010 at 12:09 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Fri, Aug 13, 2010 at 12:15 PM, Jeremy Orlow <jor...@chromium.org> > wrote: > > On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking <jo...@sicking.cc> wrote: > >> > >> On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow <jor...@chromium.org> > wrote: > >> > On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro > >> > <pablo.cas...@microsoft.com> > >> > wrote: > >> >> > >> >> From: jor...@google.com [mailto:jor...@google.com] On Behalf Of > Jeremy > >> >> Orlow > >> >> Sent: Thursday, August 12, 2010 2:18 AM > >> >> > >> >> >> I think we should first break down the use cases and look at how > >> >> >> many > >> >> >> of them just need _a_ sort order, how many of them a per-database > >> >> >> sort order > >> >> >> is ok, and how many of them would need something finer grained > (like > >> >> >> a > >> >> >> per-key ordering). > >> >> > >> >> That's reasonable. What I was thinking is that any case where you'll > >> >> use > >> >> the order of items in a store/index to display things to the user > (e.g. > >> >> a > >> >> list of contacts) you'd want the items to be in proper order for the > >> >> user's > >> >> language. That will not only match users' expectations but also match > >> >> other > >> >> applications (or even other parts of the UA) that display data based > on > >> >> the > >> >> current OS language or the users' choice of language. > >> >> > >> >> That covers a very broad spectrum of scenarios that need > >> >> language-specific > >> >> sort order. > >> >> > >> >> I find it unlikely that a single web app will need more than one > >> >> language > >> >> per database (or even per origin/OS account), given that most > >> >> applications > >> >> operate in a single language at any one point in time. > >> > > >> > A lot of people are multi-lingual and I'm sure there will be at least > >> > some > >> > apps that need different data sorted in different ways for each > language > >> > used. It's quite likely that such apps could use multiple databases > as > >> > a > >> > work-around though. (As long as they don't need to execute > transactions > >> > between them.) > >> > >> I can give some input as a multi-lingual person here. The only time > >> I've used multiple languages at the same time in an application is for > >> spell checking. In my browser I sometimes end up with setting the > >> language in one textbox to swedish, and another to english. It's often > >> annoying how poorly this use case is supported in applications > >> actually. > >> > >> However I've never been in a situation where I've wanted some lists > >> sorted in swedish and some in english. Possibly you would want to have > >> spelling suggestions for a swedish textbox sorted in swedish order, > >> and spelling suggestions for an english textbox sorted in english > >> order. Though I think it wouldn't be much problem to have the > >> different dictionaries in different databases. > >> > >> From an API point of view I think it would be pretty easy to support > >> setting collation for individual objectStores. All we'd need is > >> something like: > >> > >> interface IDBObjectStore { > >> ... > >> IDBRequest setSortingLanguage(in DOMString languageCode); > >> IDBRequest getSortingLanguage(); > >> ... > >> }; > >> > >> To call setSortingLanguage you'd need READ_WRITE access. It acts just > >> like any other writing request, with the only difference that it can > >> take a loooong time to execute. We could even add these functions to > >> IDBIndex to allow the same data to be sorted in different ways at the > >> same time. > > > > Why not put it behind setVersion and just make it an optional parameter > when > > creating objectStores and indexes? I agree with Pablo that these things > > really shouldn't be changing much--in fact, maybe it's not worth making > > them modifiable at all (without rebuilding a new objectStore/index > > yourself). > > What is the advantage of this approach? It seems more cumbersome for > authors. It brings back memories of the days when you had to recreate > a SQL table to add a column to it. > The advantage is that the API is more clear from a syntactic and performance impact standpoint. If you felt strongly, we could add a modifyObjectStore/modifyIndex method, but I don't think it's necessary. > >> However I think it's very rare that this will be needed. And there are > >> ways to somewhat work around it by using separate databases. So I > >> would probably say that lets keep it database-wide for now, and > >> reconsider in version 2. > > > > On the other hand, is there any reason not to make it > per-objectStore/index? > > As far as I can tell, it should actually be fairly light weight form an > API > > point of view: we can just add it as an optional parameter to > > createObjectStore/createIndex. From an implementation point of view, I > > really don't see this being much overhead either. So maybe we should > just > > do it? > > I don't feel very strongly. Though I'd want to check that this is > actually pretty easy to do implementation wise. Given that I think > this is a low-value feature, I'd want to make sure it's low-cost too. > How will we "check"? And should we really be basing decisions off of what's easiest to do implementation wise? And is this truly a low value feature? > > The alternative is to add a function within setVersion to set the > language > > which actually seems less elegant. > > I don't understand what you mean by this. > Have a setLanguage method on IDBDatabase that can only be called from within a setVersion transaction. In the same way removeObjectStore and company can only be called within a setVersion transaction. J
