Re: [IndexedDB] Closing on bug 9903 (collations)

On 1 June 2011 01:37, Pablo Castro <Pablo.Castro@microsoft.com> wrote:

>
> -----Original Message-----
> From: simetrical@gmail.com [mailto:simetrical@gmail.com] On Behalf Of
> Aryeh Gregor
> Sent: Tuesday, May 31, 2011 3:49 PM
>
> >> On Tue, May 31, 2011 at 6:39 PM, Pablo Castro
> >> <Pablo.Castro@microsoft.com> wrote:
> >> > No, that was poor wording on my part, I keep using "locale" in the
> wrong context. I meant to have the API take a proper collation identifier.
> The identifier can be as specific as the caller wants it to be. The
> implementation could choose to not honor some specific detail if it can't
> handle it (to the extent that doing so is allowed by the specification of
> collation names), or fail because it considers that not handling a
> particular aspect of the collation identifier would severely deviate from
> the caller's expectations.
> >>
> >> I'm not sure I understand you.  My personal opinion is that there
> >> should be no undefined behavior here.  If authors are allowed to pass
> >> collation identifiers, the spec needs to say exactly how they're to be
> >> interpreted, so the same identifier passed to two different browsers
> >> will result in the same collation, i.e., the same strings need to sort
> >> the same cross-browser.  Having only binary collation is better than
> >> having non-binary collations but not defining them, IMO.
>
> I thought BCP47 allowed implementations to drop subtags if needed. I just
> re-read the spec and it seems that it only allows to do that in constrained
> cases where you can't fit the whole name in your buffer (which wouldn't
> apply to the context discussed here). My first instinct is that this is
> quite a bit to guarantee (full consistency in collation), but it seems that
> that's what the spec is shooting for.
>
> >> > Given the amount of debate on this, could we at least agree that we
> can do binary for v1? We can then have an open item for v2 on taking
> collation names and sort according to UCA or taking callbacks and such.
> >>
> >> I'm okay with supporting only binary to start with.
>
> Great. I'll still wait a bit to see what other folks think, and then update
> the bug one way or the other.
>
> Thanks
> -pablo
>
>
The discussion sounds like it is headed in the right direction. Are there
any issues with non-unicode encodings that need to be dealt with (HTTP
headers default to ISO-8859 I think). Would people be expected to convert on
read into UTF-16 strings or use typed-arrays?


Cheers,
Keean.