Re: [IndexedDB] Design Flaws: Not Stateless, Not Treating Objects As Opaque

> Currently there are no APIs in JavaScript to compare strings using
specific collations

We dont actually need this, just a mapping from UTF-16 string to a
sort-score (binary blob).

Its true that downloading the collation tables might take time, so we could
just provide:

var blob = string_to_score('utf-16 string', 'en-US');

as a built in function to make this efficient.

I agree with the other points though.


Cheers,
Keean.


On 31 March 2011 22:38, Pablo Castro <Pablo.Castro@microsoft.com> wrote:

>
> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy
> Orlow
> Sent: Thursday, March 31, 2011 11:36 AM
>
> >> I can find a lot of stuff on collation, but not a lot about why it could
> not be done in a library. Could you summerise the reasons why this needs to
> be core functionality for me?
> >>
> >> Sorry, but that stuff is paged out of my brain.  Pablo, can you?
>  >>
> >> A library could chose to use an object store as meta-data to store the
> collation orders that it is using for various indexes for example.
>
> - Currently there are no APIs in JavaScript to compare strings using
> specific collations. There are folks that are looking into this, but it will
> need time.
> - I'm far from an expert in the topic, but from talking to folks that
> understand this well it seems that to actually implement this entirely in
> JavaScript it would mean you have to download collation tables and apply
> them as needed in callbacks. Not only this means a hit in download size/time
> for the app but also that callbacks have to either download stuff or inline
> collation rules/tables in the callback itself.
> - In pure practical terms, I suspect the 80% scenario can be covered by
> implementing this natively, having it be fast and simple to use for common
> cases. Not pushing back on the callback stuff, just saying that I find it
> valuable to have users simply say "en-US" and get what they wanted.
> - Also from the practical perspective, simple cases that don't require the
> flexibility and can avoid having to take care of making the callbacks
> perfectly consistent even as you roll out updates that may hit only some of
> the pages, use components written by someone else, etc.
> - By default we would still do binary collation (there was a question in
> the thread, I forget exactly where).
>
> Thanks
> -pablo
>
>