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

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

Received on Thursday, 31 March 2011 22:38:42 UTC