On Fri, Aug 13, 2010 at 12:15 PM, Jeremy Orlow wrote:
> On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow wrote:
>> > On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro
>> >
>> > 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 lng 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.
>> 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.
> 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.
/ Jonas
