Re: [IndexedDB] Languages for collation

2 additional questions:  What standard will define the language codes and
the associated collation algorithm?  And what's the behavior for an
implementation that doesn't support that particular language?

J

On Mon, Aug 16, 2010 at 2:20 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Mon, Aug 16, 2010 at 12:09 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Fri, Aug 13, 2010 at 12:15 PM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> > On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking <jonas@sicking.cc>
>> wrote:
>> >>
>> >> On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> >> > On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro
>> >> > <Pablo.Castro@microsoft.com>
>> >> > wrote:
>> >> >>
>> >> >> From: jorlow@google.com [mailto:jorlow@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
>