Re: [IndexedDB] Languages for collation

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