Re: New draft of FileSystem API posted
Hi Eric,
Thanks for your reply.
Actually after sending that email I had started to think that caching isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like that's
the case. So I'm almost convinced :)
One thing I'm not fully convinced yet about FileEntry / DirectoryEntry is
if we really want to make FileEntry a subclass of File.
To me it looks like they have slightly different semantics - File is an
immutable snapshot of file content, while Entry is more like a handle for
meta-level operations that actually modify the underlying disk image.
File's size attribute and slice() method assume its snapshot doesn't change
after it was captured, but FileEntry has createWriter method and it will
likely change the file content. It brings several questions: if FileEntry
== File in what timing are UAs supposed to capture a snapshot? Do we want
to have a synchronous size attribute on a mutable Entry? If we move an
Entry to another name, does its File.type need to change according to its
new name?
On Wed, Aug 11, 2010 at 1:25 PM, Eric Uhrhane wrote:
> My apologies for the slow response; I'm now back from my vacation.
>
> On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda wrote:
> > Hi Eric,
> > Thanks for brushing up the draft.
> > We had some internal discussion about the API details and came up with a
> > question regarding is{File,Directory} attributes of Entry interface.
> > It seems like user agent needs to be able to tell if a given entry is
> file
> > or directory synchronously (or from its cache), but we wonder what should
> > happen if the underlying file object is changed later. For example, we
> may
> > have a situation like this:
> > 1. a user code gets (or creates) a file entry.
> > 2. another flow of the code (or another code in the same origin) removes
> the
> > same entry and creates a *directory* at the same path.
> > 3. the original code refers isFile attribute of the entry. -- should it
> be
> > true or false?
>
> My intention was that the UA would look up that information when first
> creating the Entry and keep it cached. It's not the kind of thing
> that changes very often, so I didn't think we needed it to be a live
> query every time. If the user tries to write to a file that's become
> a directory, or vice-versa, that's what INVALID_STATE_ERROR is for.
This is an unusual error, thus it's appropriate that it be handled via
> exception.
> If an Entry is just a reference (i.e. a pathname) of a system file entity,
> > it would look natural that it is resolved at run-time thus returns false
> in
> > the above case. But if so we'll have two problems: 1) we'll need to
> make
> > synchronous stat calls to get the attribute values, and 2) as we have
> > different interfaces for file and directory, we may end up with having
> > invalid FileEntry objects for directories - or vice versa.
> > Would it be possible to have a single unified interface for file and
> > directory and let scripts figure out the info at runtime (e.g. in each
> > asynchronous filesystem operation)?
>
> Do you mean, allow all file operations and directory operation, and
> fail if you use the wrong one? UAs already have to fail on operations
> that don't make sense [or fail in the underlying implementation],
> whether or not we keep a unified interface, so I think that would just
> clutter up each subtype with the others' methods.
>
> If I'm misunderstanding you, please give an example of your proposed
> interface and a situation which it would improve.
You're not misunderstanding me. I meant if UAs didn't cache the
information that an entry is file or directory it would be natural to make
wrong operations fail at run-time, but otherwise I fully agree that
cluttering up subtypes with irrelevant methods is not a good idea.
> On Wed, Jul 7, 2010 at 6:50 PM, Eric Uhrhane wrote:
> >>
> >> I've posted a new draft of File API: Directories and System [1]. In
> >> this draft I've rolled in quite a bit of feedback that I received
> >> since first posting it on DAP--many apologies for the delay. This is
> >> the first draft produced since we agreed to move this spec from DAP to
> >> WebApps; I hope those of you who have time will give it a look and let
> >> me know what you think.
> >>
> >> In general I've tried to address any comment I was sent and had not
> >> already addressed via email. The few that didn't make it in, I've
> >> responded to below.
> >>
> >> My thanks to Robin Berjon and Mike Clement for all their feedback.
> >>
> >> Robin:
> >> - "data stored there by the application should not be deleted by the
> >> UA without user intervention", "UA should require permission from the
> >> user", "The application may of course delete it at will" -> these
> >> sound like real conformance statements, therefore SHOULD, SHOULD NOT,
> >> and MAY.
> >>
> >> Those are in a non-normative section; is that language still appropriate
RE: [IndexedDB] Languages for collation
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow Sent: Thursday, August 12, 2010 3:36 AM >> On Thu, Aug 12, 2010 at 11:19 AM, Jonas Sicking wrote: >> On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro >> wrote: >> > We had some discussions about collation algorithms and such in the past, >> > but I don't think we have settled on the language aspect of it. In order >> > to have stores and indexes sort character-based keys in a way that is >> > consistent with users' expectations we'll have to take indication in the >> > API of what language we should use to collate strings. >> > >> > Trying to take a minimalist approach, we could add an optional parameter >> > on the database open call that indicates the language to use (e.g. "en" or >> > "en-UK", etc.). If the language is not specified and the database does not >> > exist, then we can use the current browser/OS language to create the >> > database. If not specified and database already exists, then use the one >> > it's already there (this accommodates the fact that a user may be able to >> > change their default language in the browser/OS after the database has >> > been created using the default). If the language is specified and the >> > database already exists and the specified language is not the one the >> > database has then we'll throw an exception (same behavior as with >> > "description", although we have that one in flight right now as well). >> > >> > We should probably also add a read-only attribute to the database object >> > that exposes the language. >> > >> > If this works for folks I can write a proposal for the specific changes to >> > the spec. >> If we make it part of the database open call, then that makes it >> impossible to change the sorting order of an existing database, no? >> This seems like it could be a problem. I.e. it quite possible that an >> application will want to allow the user to change the sorting >> language, for example when changing the language of the UI. >> >> One solution would be to allow language to be set as part of the >> setVersion call. >> >> Whether it's per-database or more fine grained I think it absolutely must be >> part of setVersion. Changing the language will be a very heavyweight >> operation that'll require a similar level of isolation to "schema" changes >> of the database. (Not sure how I missed this point of Pablo's original >> email.) Yes, changing the collection would effectively mean re-creating all the stores and indexes. At a very minimum it needs to be a setVersion thing. I also don't think it would be too crazy to not support changing collations period. In the unusual case where a user must absolutely do this, it can be done by creating a separate database and copying the data over using the APIs.
RE: [IndexedDB] Languages for collation
From: jor...@google.com [mailto:jor...@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. >> Are there work-arounds for getting an UCA ordered data structure to hold >> data other language's order? For example, I could imagine it'd be possible >> to do some sort of encode step on the data before insertion (and decode on >> removal) that would make UCA work. I have no idea, but if such algorithms >> existed and were well understood, then it'd definitely make me lean towards >> punting language specification to v2. I'm not sure I understand this paragraph. "UCA ordered" may not mean much more than just ordering using a binary collation if the language is not specified. While this is typically not an issue in English, in other languages this introduces a varying level of deviation from users' expectations. Given that different languages have conflicting rules for collation, I'm not sure how this can be generalized independently of the language. Even in the UCA specification [1] the aspect of input language is mentioned as the most important feature of collation. [1] http://www.unicode.org/reports/tr10/
[Bug 10357] New: [IndexedDB] Remove the SNAPSHOT_READ transaction mode
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10357 Summary: [IndexedDB] Remove the SNAPSHOT_READ transaction mode Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: pablo.cas...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org We currently have two read-only transaction modes, READ_ONLY and SNAPSHOT_READ, that are identical in every aspect (point-in-time consistency for readers, allow multiple concurrent readers, etc.), except that they have different concurrency characteristics, with READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers come and go while readers are active. We agreed (see [1]) that we could remove the concept and only have READ_ONLY, leaving it up to the implementation whether writers block readers or readers are allowed and some mechanism is used to maintain point-in-time consistency semantics. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0485.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR] Redirects
On Thu, Aug 12, 2010 at 3:03 PM, Anne van Kesteren wrote: > On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras wrote: >> Hi ! >> >> a) >> If a XHR follows a redirection chain, does the API provide a way to >> retrieve the final url? > > Apart from document.responseXML.URL I do not think so. And I'm not sure if > document.responseXML.URL is supposed to work. I've run into this limitation before as well. Unfortunately, responseXML.URL doesn't get populated if the response isn't XML. The use case is I want to know where the response came from (as opposed to where the first request in the redirect chain went). :) Adam
Re: [XHR] Redirects
On , Anne van Kesteren wrote: On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. It might not be an xml file, hence resonseXML is not defined and that's no good. b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. In my specific case, I had an url to a media file which I needed to feed to a plugin. But the plugin did not handle redirects. So I needed to do a HEAD request, and check if it returned 302 and read the Location header. But due to the implicit redirecting handling, and no way to access the final url, that was impossible. So, two problems in one. Between the boolean and an integer, the integer is more useful, although seeing long redirection chains is somewhat rare and overkill.
Re: [XHR] Redirects
On Thu, 12 Aug 2010 15:07:50 +0200, João Eiras wrote: Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? Apart from document.responseXML.URL I do not think so. And I'm not sure if document.responseXML.URL is supposed to work. b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj. What is the use case? We might add something like this at some point (probably by way of a followRedirects boolean) but so far the use cases have not been really strong so it has not been given much priority. -- Anne van Kesteren http://annevankesteren.nl/
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
On Thu, Aug 12, 2010 at 2:46 PM, Nikunj Mehta wrote: > > On Aug 12, 2010, at 2:22 PM, Pablo Castro wrote: > >> We currently have two read-only transaction modes, READ_ONLY and >> SNAPSHOT_READ. As we map this out to implementation we ran into various >> questions that made me wonder whether we have the right set of modes. >> >> It seems that READ_ONLY and SNAPSHOT_READ are identical in every aspect >> (point-in-time consistency for readers, allow multiple concurrent readers, >> etc.), except that they have different concurrency characteristics, with >> READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers >> come and go while readers are active. Does that match everybody's >> interpretation? > > That is the intention. That was my understanding too. >> Assuming that interpretation, then I'm not sure if we need both. Should we >> consider having only READ_ONLY, where transactions are guaranteed a stable >> view of the world regardless of the implementation strategy, and then let >> implementations either block writers or version the data? I understand that >> this introduces variability in the reader-writer interaction. On the other >> hand, I also suspect that the cost of SNAPSHOT_READ will also vary a lot >> across implementations (e.g. mvcc-based stores versus non-mvcc stores that >> will have to make copies of all stores included in a transaction to support >> this mode). > > The main reason to separate the two was to correctly set expectations. It > seems fine to postpone this feature to a future date. Sounds good to me. / Jonas
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
On Aug 12, 2010, at 2:22 PM, Pablo Castro wrote: > We currently have two read-only transaction modes, READ_ONLY and > SNAPSHOT_READ. As we map this out to implementation we ran into various > questions that made me wonder whether we have the right set of modes. > > It seems that READ_ONLY and SNAPSHOT_READ are identical in every aspect > (point-in-time consistency for readers, allow multiple concurrent readers, > etc.), except that they have different concurrency characteristics, with > READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers come > and go while readers are active. Does that match everybody's interpretation? That is the intention. > > Assuming that interpretation, then I'm not sure if we need both. Should we > consider having only READ_ONLY, where transactions are guaranteed a stable > view of the world regardless of the implementation strategy, and then let > implementations either block writers or version the data? I understand that > this introduces variability in the reader-writer interaction. On the other > hand, I also suspect that the cost of SNAPSHOT_READ will also vary a lot > across implementations (e.g. mvcc-based stores versus non-mvcc stores that > will have to make copies of all stores included in a transaction to support > this mode). The main reason to separate the two was to correctly set expectations. It seems fine to postpone this feature to a future date.
Re: [IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
On Thu, Aug 12, 2010 at 10:22 PM, Pablo Castro wrote: > We currently have two read-only transaction modes, READ_ONLY and > SNAPSHOT_READ. As we map this out to implementation we ran into various > questions that made me wonder whether we have the right set of modes. > > It seems that READ_ONLY and SNAPSHOT_READ are identical in every aspect > (point-in-time consistency for readers, allow multiple concurrent readers, > etc.), except that they have different concurrency characteristics, with > READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers > come and go while readers are active. Does that match everybody's > interpretation? > Yup. Assuming that interpretation, then I'm not sure if we need both. Should we > consider having only READ_ONLY, where transactions are guaranteed a stable > view of the world regardless of the implementation strategy, and then let > implementations either block writers or version the data? I understand that > this introduces variability in the reader-writer interaction. On the other > hand, I also suspect that the cost of SNAPSHOT_READ will also vary a lot > across implementations (e.g. mvcc-based stores versus non-mvcc stores that > will have to make copies of all stores included in a transaction to support > this mode). This seems reasonable to me. J
[IndexedDB] READ_ONLY vs SNAPSHOT_READ transactions
We currently have two read-only transaction modes, READ_ONLY and SNAPSHOT_READ. As we map this out to implementation we ran into various questions that made me wonder whether we have the right set of modes. It seems that READ_ONLY and SNAPSHOT_READ are identical in every aspect (point-in-time consistency for readers, allow multiple concurrent readers, etc.), except that they have different concurrency characteristics, with READ_ONLY blocking writers and SNAPSHOT_READ allowing concurrent writers come and go while readers are active. Does that match everybody's interpretation? Assuming that interpretation, then I'm not sure if we need both. Should we consider having only READ_ONLY, where transactions are guaranteed a stable view of the world regardless of the implementation strategy, and then let implementations either block writers or version the data? I understand that this introduces variability in the reader-writer interaction. On the other hand, I also suspect that the cost of SNAPSHOT_READ will also vary a lot across implementations (e.g. mvcc-based stores versus non-mvcc stores that will have to make copies of all stores included in a transaction to support this mode). Thanks -pablo
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 11:44 AM, Jeremy Orlow wrote:
> On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu wrote:
>> Given that open() is one of those functions that are likely to grow in
>> parameters over time, I wonder if we should consider taking an object as the
>> second argument with names/values(e.g. open("mydatabase", { description:
>> "foo" }); ). That would allow us to keep the minimum specification small and
>> easily add more parameters later without resulting un hard to read code that
>> has a bunch of "undefined" in arguments.
>>
>> The only thing I'm not sure is if there is precedent of doing this in
>> one of the standard APIs.
>
> That sounds great to me.
Thank god, maybe we can *finally* make this a pattern in the web
platform. Javascript's lack of keyword parameters is already a pain;
the inexplicable resistance to adding this common hack around that
into the web platform has pained me every time.
~TJ
Re: [IndexedDB] question about description argument of IDBFactory::open()
That sounds great to me.
On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu wrote:
> On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu
> wrote:
> > On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
> > wrote:
> >>
> >> From: public-webapps-requ...@w3.org [mailto:
> public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow
> >> Sent: Thursday, August 12, 2010 3:59 AM
> >>
> On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking
> wrote:
> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow
> wrote:
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
> > One quesiton though: if they pass in null or undefined, do we want
> to
> > interpret this as the argument not being passed in or simply let
> them
> > convert to "undefined" and "null" (which is the default behavior in
> WebIDL,
> > I believe). I feel somewhat strongly we should do the former.
> Especially
> > since the latter would make it impossible to add additional
> parameters to
> > .open() in the future.
> I don't understand why it would make it impossible to add optional
> parameters in the future. Wouldn't it be a matter of people writing
>
> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
>
> vs.
>
> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
>
> So "" is assumed to mean "don't update"? My assumption was that ""
> meant empty description.
>
> It seems silly to make someone replace the description with a space
> (or something like that) if they truly want to zero it out. And it seems
> silly to ever make your description be >> "null". So it seemed natural to
> make null and/or undefined be such a signal.
> >>
> >> Given that open() is one of those functions that are likely to grow in
> parameters over time, I wonder if we should consider taking an object as the
> second argument with names/values(e.g. open("mydatabase", { description:
> "foo" }); ). That would allow us to keep the minimum specification small and
> easily add more parameters later without resulting un hard to read code that
> has a bunch of "undefined" in arguments.
> >
> > This is fine with me.
> >
> >> The only thing I'm not sure is if there is precedent of doing this in
> one of the standard APIs.
> >>
> >
> > There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
> >
>
> Sorry, I meant PositionOptions:
>
> http://dev.w3.org/geo/api/spec-source.html#position-options
>
> Andrei
>
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu wrote:
> On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
> wrote:
>>
>> From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
>> On Behalf Of Jeremy Orlow
>> Sent: Thursday, August 12, 2010 3:59 AM
>>
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking wrote:
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
> One quesiton though: if they pass in null or undefined, do we want to
> interpret this as the argument not being passed in or simply let them
> convert to "undefined" and "null" (which is the default behavior in
> WebIDL,
> I believe). I feel somewhat strongly we should do the former.
> Especially
> since the latter would make it impossible to add additional parameters to
> .open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
vs.
indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
So "" is assumed to mean "don't update"? My assumption was that "" meant
empty description.
It seems silly to make someone replace the description with a space (or
something like that) if they truly want to zero it out. And it seems
silly to ever make your description be >> "null". So it seemed natural to
make null and/or undefined be such a signal.
>>
>> Given that open() is one of those functions that are likely to grow in
>> parameters over time, I wonder if we should consider taking an object as the
>> second argument with names/values(e.g. open("mydatabase", { description:
>> "foo" }); ). That would allow us to keep the minimum specification small and
>> easily add more parameters later without resulting un hard to read code that
>> has a bunch of "undefined" in arguments.
>
> This is fine with me.
>
>> The only thing I'm not sure is if there is precedent of doing this in one of
>> the standard APIs.
>>
>
> There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
>
Sorry, I meant PositionOptions:
http://dev.w3.org/geo/api/spec-source.html#position-options
Andrei
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
wrote:
>
> From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
> Behalf Of Jeremy Orlow
> Sent: Thursday, August 12, 2010 3:59 AM
>
>>> On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking wrote:
>>> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow wrote:
>>> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
>>> > One quesiton though: if they pass in null or undefined, do we want to
>>> > interpret this as the argument not being passed in or simply let them
>>> > convert to "undefined" and "null" (which is the default behavior in
>>> > WebIDL,
>>> > I believe). I feel somewhat strongly we should do the former. Especially
>>> > since the latter would make it impossible to add additional parameters to
>>> > .open() in the future.
>>> I don't understand why it would make it impossible to add optional
>>> parameters in the future. Wouldn't it be a matter of people writing
>>>
>>> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
>>>
>>> vs.
>>>
>>> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
>>>
>>> So "" is assumed to mean "don't update"? My assumption was that "" meant
>>> empty description.
>>>
>>> It seems silly to make someone replace the description with a space (or
>>> something like that) if they truly want to zero it out. And it seems silly
>>> to ever make your description be >> "null". So it seemed natural to make
>>> null and/or undefined be such a signal.
>
> Given that open() is one of those functions that are likely to grow in
> parameters over time, I wonder if we should consider taking an object as the
> second argument with names/values(e.g. open("mydatabase", { description:
> "foo" }); ). That would allow us to keep the minimum specification small and
> easily add more parameters later without resulting un hard to read code that
> has a bunch of "undefined" in arguments.
This is fine with me.
> The only thing I'm not sure is if there is precedent of doing this in one of
> the standard APIs.
>
There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
Thanks,
Andei
RE: [IndexedDB] question about description argument of IDBFactory::open()
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM
>> On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking wrote:
>> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow wrote:
>> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
>> > One quesiton though: if they pass in null or undefined, do we want to
>> > interpret this as the argument not being passed in or simply let them
>> > convert to "undefined" and "null" (which is the default behavior in WebIDL,
>> > I believe). I feel somewhat strongly we should do the former. Especially
>> > since the latter would make it impossible to add additional parameters to
>> > .open() in the future.
>> I don't understand why it would make it impossible to add optional
>> parameters in the future. Wouldn't it be a matter of people writing
>>
>> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
>>
>> vs.
>>
>> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
>>
>> So "" is assumed to mean "don't update"? My assumption was that "" meant
>> empty description.
>>
>> It seems silly to make someone replace the description with a space (or
>> something like that) if they truly want to zero it out. And it seems silly
>> to ever make your description be >> "null". So it seemed natural to make
>> null and/or undefined be such a signal.
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open("mydatabase", { description: "foo"
}); ). That would allow us to keep the minimum specification small and easily
add more parameters later without resulting un hard to read code that has a
bunch of "undefined" in arguments. The only thing I'm not sure is if there is
precedent of doing this in one of the standard APIs.
Thanks
-pablo
Is anyone attending "Web science: A new frontier" at the Royal Society?
Is anyone attending "Web science: A new frontier" at the Royal Society? http://royalsociety.org/Web-science-a-new-frontier cheers Jonathan
[widgets] Draft minutes 12 August 2010 voice conf
Below are the draft minutes from the August 12 Widgets voice conference WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before August 26 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow Present: Art, Robin, Richard Tibbett, Wonsuk Lee Regrets: Frederick, Marcos Chair: Art Scribe: Art [09:02] Topic: Review and tweak agenda [09:02] AB: the draft agenda was posted yesterday ( http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0447.html ). The two specs on the agenda are Widget Interface and the Widget URI scheme. Any change requests? [09:03] RT: I would like to talk about Widget Updates spec [09:03] AB: ok, will add that to the end of the meeting [09:03] Topic: Announcements [09:04] AB: any short announcements today? [09:04] Topic: TWI spec: Action-568 [09:04] AB: earlier this week discussion on openURL removal continued ( http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0394.html ) [09:04] AB: Bryan Sullivan had some comments [09:05] ... I was hoping Bryan would join today but he hasn't [09:05] AB: I believe Marcos position is very clear [09:05] ... he wants it removed from the spec [09:06] RB: as far as I am concerned, agree it is useful [09:06] ... but it is also problematic [09:06] ... Think it should be solved somewhere else [09:06] RT: yes, there is a complexity issue here [09:06] ... so I agree with Marcos and Robin [09:06] RB: if we remove it, we should be able to go straight to REC [09:07] AB: we could go to PR but not REC because of some dependency issues [09:07] RB: dependency on HTML5? [09:07] AB: yes that is one [09:08] AB: I also tend to agree with the arguments to remove the functionality [09:08] ... and defer to some other spec for equivalent functionality [09:08] AB: I'll start an explict CfC about removing this method from the spec [09:09] +1 [09:09] ... I'd like to make sure everyone has an opportunity to state their position [09:09] yep, sounds good [09:09] ACTION: barstow start a CfC about openURL and Action-568 [09:09]* trackbotnoticed an ACTION. Trying to create it. [09:09] Created ACTION-569 - Start a CfC about openURL and Action-568 [on Arthur Barstow - due 2010-08-19]. [09:09] AB: anything else on that topic for today? [09:09] [ No ] [09:09] Topic: URI Scheme spec [09:10] AB: it has been a while since we discussed the widget: scheme spec ( http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ ) [09:10] AB: what's the status and plan? [09:10] RB: I still need to address some issues [09:10] ... I plan to make it a priority [09:10] ... hope to finish by the end of the month [09:11] ... I know the action items [09:11] AB: ok, great [09:11] AB: does anyone have any implementation status for this spec? [09:11] RB: I found it easy to implement [09:12] AB: the spec says authors shouldn't use this scheme [09:12] ... so what's the use case [09:12] RB: when using the DOM, need to determine an absolute URI [09:12] ... so impls need it [09:13] ... it could also to lead to security hole if an implementor was to use something like a file: URI [09:13] ... at runtime it is needed [09:13] ... e.g. to reuse a web runtime engine [09:13] It's a very useful spec and I believe we require it for impl. down the line. [09:13] ...at Opera [09:14] AB: anything else on that spec? [09:14] RT: we use it for some projects [09:14] ... good to get rid of the file: issue [09:14] Topic: Widget Updates spec [09:15] widgets updates: http://dev.w3.org/2006/waf/widgets-updates/ [09:15] RT: I've been working with Marcos on this spec [09:15] ... clarified update description [09:15] ... started an alogorithm to do the update [09:15] ... would like to get some feedback [09:16] AB: I haven't looked at the changes [09:16] RB: same here although I will do so shortly [09:16] RT: addresses comparing signatures for the installed widget and the update widget [09:17] ... so please do take a look [09:17] AB: to get broader review, it often helps to publish a new version [09:17] AB: when will it be ready for a new pub? [09:18] RT: I have another couple of weeks of work to do before it is ready [09:18] AB: ok, that sounds good [09:18] I want to clarify the Verification Process as it is largely just a placeholder at present [09:19] AB: perhaps we can put it on the agenda for the next call which is probably in 2 weeks [09:19] RT: any feedback now would be good [09:19] AB: I'll ask for internal review [09:20] AB: are there some existing protocols this functionality could be layered on? [09:20] ... e.g. the DM stuff from OMA [09:20] RT: yes, there is some existing wo
[XHR] Redirects
Hi ! a) If a XHR follows a redirection chain, does the API provide a way to retrieve the final url? b) Could there be a way to opt-in into not following redirection chains ? For instance, a redirectCount property, default value would be something like Infinity (the user agent could then cap the maximum amount of redirects), and setting it to 0 would prevent any redirect, and setting to something greater than 0 would then limit the redirect chain to that number. If the last http request was 302 and the redirection prevented, then the 302 status code and the last response headers would be returned by the XHR obj.
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking wrote:
> On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow wrote:
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
> > One quesiton though: if they pass in null or undefined, do we want to
> > interpret this as the argument not being passed in or simply let them
> > convert to "undefined" and "null" (which is the default behavior in
> WebIDL,
> > I believe). I feel somewhat strongly we should do the former.
> Especially
> > since the latter would make it impossible to add additional parameters to
> > .open() in the future.
>
> I don't understand why it would make it impossible to add optional
> parameters in the future. Wouldn't it be a matter of people writing
>
> indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
>
> vs.
>
> indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
>
So "" is assumed to mean "don't update"? My assumption was that "" meant
empty description.
It seems silly to make someone replace the description with a space (or
something like that) if they truly want to zero it out. And it seems silly
to ever make your description be "null". So it seemed natural to make null
and/or undefined be such a signal.
J
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow wrote:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
> One quesiton though: if they pass in null or undefined, do we want to
> interpret this as the argument not being passed in or simply let them
> convert to "undefined" and "null" (which is the default behavior in WebIDL,
> I believe). I feel somewhat strongly we should do the former. Especially
> since the latter would make it impossible to add additional parameters to
> .open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open("mydatabase", "", SOME_OTHER_PARAM);
vs.
indexeddb.open("mydatabase", null, SOME_OTHER_PARAM);
/ Jonas
Re: [IndexedDB] question about description argument of IDBFactory::open()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 One quesiton though: if they pass in null or undefined, do we want to interpret this as the argument not being passed in or simply let them convert to "undefined" and "null" (which is the default behavior in WebIDL, I believe). I feel somewhat strongly we should do the former. Especially since the latter would make it impossible to add additional parameters to .open() in the future. J On Thu, Aug 12, 2010 at 11:37 AM, Jeremy Orlow wrote: > I don't feel strongly. > > I'll file a bug for our proposed solution. > > On Thu, Aug 12, 2010 at 1:01 AM, Jonas Sicking wrote: > >> On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow >> wrote: >> > On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking >> wrote: >> >> >> >> On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu >> >> wrote: >> >> > On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking >> wrote: >> >> >> On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow > > >> >> >> wrote: >> >> >>> On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow < >> jor...@chromium.org> >> >> >>> wrote: >> >> >> >> On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu < >> andr...@google.com> >> >> wrote: >> >> > >> >> > On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow < >> jor...@chromium.org> >> >> > wrote: >> >> > > On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking >> >> >> > > wrote: >> >> > >> >> >> > >> On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow >> >> > >> >> >> > >> wrote: >> >> > >> > On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu >> >> > >> > >> >> > >> > wrote: >> >> > >> >> >> >> > >> >> On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow >> >> > >> >> >> >> > >> >> wrote: >> >> > >> >> > I'm pretty sure opening a database with a different >> >> > >> >> > description >> >> > >> >> > is >> >> > >> >> > actually >> >> > >> >> > already specified: the new one takes precedent. Take a >> look >> >> > >> >> > at >> >> > >> >> > the >> >> > >> >> > algorithm for database opening; I'm pretty sure it's >> there. >> >> > >> >> > When talking to Andrei earlier tonight I thought we'd >> >> > >> >> > probably >> >> > >> >> > want >> >> > >> >> > to >> >> > >> >> > make >> >> > >> >> > it optional, but now I'm thinking maybe we shouldn't. >> >> > >> >> > You're >> >> > >> >> > right, >> >> > >> >> > Shawn, >> >> > >> >> > that the description can be useful for many reasons. And >> >> > >> >> > although it >> >> > >> >> > seems >> >> > >> >> > redundant for a developer to pass in the description >> every >> >> > >> >> > time, >> >> > >> >> > I >> >> > >> >> > actually >> >> > >> >> > can't think of any reason why a developer wouldn't want >> to. >> >> > >> >> >> >> > >> >> Actually, I think it's pretty inconvenient to have to >> specify >> >> > >> >> a >> >> > >> >> description every time, especially since I am not sure >> >> > >> >> developers >> >> > >> >> would want to change the description very often. I think we >> >> > >> >> should >> >> > >> >> allow a null string for future connections as Shawn >> suggested. >> >> > >> > >> >> > >> > How do developers distinguish between when they're opening a >> >> > >> > database >> >> > >> > for >> >> > >> > the first time or not? Normally they'd look at the version, >> >> > >> > but >> >> > >> > that's >> >> > >> > not >> >> > >> > available until _after_ you've supplied the description (and >> >> > >> > presumably >> >> > >> > some >> >> > >> > UAs might have asked the user if it's OK or something like >> >> > >> > that). >> >> > >> > If >> >> > >> > the >> >> > >> > spec has a way to enumerate databases (something we've >> talked >> >> > >> > about >> >> > >> > doing) >> >> > >> > then it's possible that the developer could decide whether >> or >> >> > >> > not to >> >> > >> > pass in >> >> > >> > a version string that way. But why would they do this? >> >> > >> > So the only possible reason I could see for someone doing >> this >> >> > >> > is if >> >> > >> > they >> >> > >> > open a database in several places in one page and they can >> >> > >> > somehow guarantee that one of them happens first. The first >> >> > >> > question >> >> > >> > here >> >> > >> > would be "but why?". And the second question is whether we >> >> > >> > trust >> >> > >> > users >> >> > >> > to >> >> > >> > for sure know the ordering that things are opened. >> >> > >> > On the other hand, it doesn't seem that hard to supply a >> >> > >> > description >> >> > >> > every >> >> > >> > time it's opened. I mean you just define it in one places >> >> > >> > within >> >> > >> > your >> >> > >> > script and use that. Or, better yet, just save the database >> to >> >> > >
[Bug 10349] New: [IndexedDB] IDBDatabase.description should be removed from the spec and made optional
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 Summary: [IndexedDB] IDBDatabase.description should be removed from the spec and made optional Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: andr...@google.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Per the "[IndexedDB] question about description argument of IDBFactory::open()" thread [1], we shouldremove IDBDatabase.description and make the param optional. [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0459.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [IndexedDB] question about description argument of IDBFactory::open()
I don't feel strongly. I'll file a bug for our proposed solution. On Thu, Aug 12, 2010 at 1:01 AM, Jonas Sicking wrote: > On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow wrote: > > On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking > wrote: > >> > >> On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu > >> wrote: > >> > On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking > wrote: > >> >> On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow > >> >> wrote: > >> >>> On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow > > >> >>> wrote: > >> > >> On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu < > andr...@google.com> > >> wrote: > >> > > >> > On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow < > jor...@chromium.org> > >> > wrote: > >> > > On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking > > >> > > wrote: > >> > >> > >> > >> On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow > >> > >> > >> > >> wrote: > >> > >> > On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu > >> > >> > > >> > >> > wrote: > >> > >> >> > >> > >> >> On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow > >> > >> >> > >> > >> >> wrote: > >> > >> >> > I'm pretty sure opening a database with a different > >> > >> >> > description > >> > >> >> > is > >> > >> >> > actually > >> > >> >> > already specified: the new one takes precedent. Take a > look > >> > >> >> > at > >> > >> >> > the > >> > >> >> > algorithm for database opening; I'm pretty sure it's > there. > >> > >> >> > When talking to Andrei earlier tonight I thought we'd > >> > >> >> > probably > >> > >> >> > want > >> > >> >> > to > >> > >> >> > make > >> > >> >> > it optional, but now I'm thinking maybe we shouldn't. > >> > >> >> > You're > >> > >> >> > right, > >> > >> >> > Shawn, > >> > >> >> > that the description can be useful for many reasons. And > >> > >> >> > although it > >> > >> >> > seems > >> > >> >> > redundant for a developer to pass in the description every > >> > >> >> > time, > >> > >> >> > I > >> > >> >> > actually > >> > >> >> > can't think of any reason why a developer wouldn't want > to. > >> > >> >> > >> > >> >> Actually, I think it's pretty inconvenient to have to > specify > >> > >> >> a > >> > >> >> description every time, especially since I am not sure > >> > >> >> developers > >> > >> >> would want to change the description very often. I think we > >> > >> >> should > >> > >> >> allow a null string for future connections as Shawn > suggested. > >> > >> > > >> > >> > How do developers distinguish between when they're opening a > >> > >> > database > >> > >> > for > >> > >> > the first time or not? Normally they'd look at the version, > >> > >> > but > >> > >> > that's > >> > >> > not > >> > >> > available until _after_ you've supplied the description (and > >> > >> > presumably > >> > >> > some > >> > >> > UAs might have asked the user if it's OK or something like > >> > >> > that). > >> > >> > If > >> > >> > the > >> > >> > spec has a way to enumerate databases (something we've talked > >> > >> > about > >> > >> > doing) > >> > >> > then it's possible that the developer could decide whether or > >> > >> > not to > >> > >> > pass in > >> > >> > a version string that way. But why would they do this? > >> > >> > So the only possible reason I could see for someone doing > this > >> > >> > is if > >> > >> > they > >> > >> > open a database in several places in one page and they can > >> > >> > somehow guarantee that one of them happens first. The first > >> > >> > question > >> > >> > here > >> > >> > would be "but why?". And the second question is whether we > >> > >> > trust > >> > >> > users > >> > >> > to > >> > >> > for sure know the ordering that things are opened. > >> > >> > On the other hand, it doesn't seem that hard to supply a > >> > >> > description > >> > >> > every > >> > >> > time it's opened. I mean you just define it in one places > >> > >> > within > >> > >> > your > >> > >> > script and use that. Or, better yet, just save the database > to > >> > >> > a > >> > >> > variable > >> > >> > and call open once early on in initialization. That'll make > >> > >> > things > >> > >> > less > >> > >> > async anyway. > >> > >> > Am I missing something here? > >> > >> > >> > >> I have actually been thinking that it's likely fairly common to > >> > >> be > >> > >> opening a database in several different locations and know > which > >> > >> ones > >> > >> should always be reopening an existing database. > >> > >> > >> > >> I don't have any data on this though. > >> > > > >> > > Neither do I. > >> > > Well, if we make it optional based on the assu
Re: [IndexedDB] Languages for collation
On Thu, Aug 12, 2010 at 11:19 AM, Jonas Sicking wrote: > On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro > wrote: > > We had some discussions about collation algorithms and such in the past, > but I don't think we have settled on the language aspect of it. In order to > have stores and indexes sort character-based keys in a way that is > consistent with users' expectations we'll have to take indication in the API > of what language we should use to collate strings. > > > > Trying to take a minimalist approach, we could add an optional parameter > on the database open call that indicates the language to use (e.g. "en" or > "en-UK", etc.). If the language is not specified and the database does not > exist, then we can use the current browser/OS language to create the > database. If not specified and database already exists, then use the one > it's already there (this accommodates the fact that a user may be able to > change their default language in the browser/OS after the database has been > created using the default). If the language is specified and the database > already exists and the specified language is not the one the database has > then we'll throw an exception (same behavior as with "description", although > we have that one in flight right now as well). > > > > We should probably also add a read-only attribute to the database object > that exposes the language. > > > > If this works for folks I can write a proposal for the specific changes > to the spec. > > If we make it part of the database open call, then that makes it > impossible to change the sorting order of an existing database, no? > This seems like it could be a problem. I.e. it quite possible that an > application will want to allow the user to change the sorting > language, for example when changing the language of the UI. > > One solution would be to allow language to be set as part of the > setVersion call. > Whether it's per-database or more fine grained I think it absolutely must be part of setVersion. Changing the language will be a very heavyweight operation that'll require a similar level of isolation to "schema" changes of the database. (Not sure how I missed this point of Pablo's original email.) J
Re: [IndexedDB] Languages for collation
On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro wrote: > We had some discussions about collation algorithms and such in the past, but > I don't think we have settled on the language aspect of it. In order to have > stores and indexes sort character-based keys in a way that is consistent with > users' expectations we'll have to take indication in the API of what language > we should use to collate strings. > > Trying to take a minimalist approach, we could add an optional parameter on > the database open call that indicates the language to use (e.g. "en" or > "en-UK", etc.). If the language is not specified and the database does not > exist, then we can use the current browser/OS language to create the > database. If not specified and database already exists, then use the one it's > already there (this accommodates the fact that a user may be able to change > their default language in the browser/OS after the database has been created > using the default). If the language is specified and the database already > exists and the specified language is not the one the database has then we'll > throw an exception (same behavior as with "description", although we have > that one in flight right now as well). > > We should probably also add a read-only attribute to the database object that > exposes the language. > > If this works for folks I can write a proposal for the specific changes to > the spec. If we make it part of the database open call, then that makes it impossible to change the sorting order of an existing database, no? This seems like it could be a problem. I.e. it quite possible that an application will want to allow the user to change the sorting language, for example when changing the language of the UI. One solution would be to allow language to be set as part of the setVersion call. / Jonas
Re: [IndexedDB] Languages for collation
On Thu, Aug 12, 2010 at 8:28 AM, Pablo Castro wrote: > > From: Mikeal Rogers [mailto:mikeal.rog...@gmail.com] > Sent: Wednesday, August 11, 2010 11:35 PM > > >> Why not just use the unicode collation algorithm? > >> > >> Then you won't have to hint the locale. > > Unless I'm missing something, the UCA defines the general algorithm for > collating strings but you still need to know the language in order to sort > strings properly in that language. For example, in Spanish the letters "c" > and "h" together (e.g. in "chau" (bye)) sort as a single letter, causing > the expected sort order to be different from English where they are always > two independent letters (e.g. so "chau" comes before "cuando" (when) when > sorted in English, but after when sorted in Spanish). > > >> > >> http://en.wikipedia.org/wiki/Unicode_collation_algorithm > >> > >> CouchDB uses some definitions around sorting complex types like arrays > and objects but when it comes down to sorting strings it just defaults to to > the unicode collation algorithm and all the locale's are happy. > >> > >> -Mikeal > >> > >> On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro < > pablo.cas...@microsoft.com> wrote: > >> We had some discussions about collation algorithms and such in the past, > but I don't think we have settled on the language aspect of it. In order to > have stores and indexes sort character-based keys in a way that is > consistent with users' expectations we'll have to take indication in the API > of what language we should use to collate strings. > >> > >> Trying to take a minimalist approach, we could add an optional parameter > on the database open call that indicates the language to use (e.g. "en" or > "en-UK", etc.). If the language is not specified and the database does not > exist, then we can use the current browser/OS language to create the > database. If not specified and database already exists, then use the one > it's already there (this accommodates the fact that a user may be able to > change their default language in the browser/OS after the database has been > created using the default). If the language is specified and the database > already exists and the specified language is not the one the database has > then we'll throw an exception (same behavior as with "description", although > we have that one in flight right now as well). > >> > >> We should probably also add a read-only attribute to the database object > that exposes the language. > 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). Are there work-arounds for getting an UCA ordered data structure to hold data other language's order? For example, I could imagine it'd be possible to do some sort of encode step on the data before insertion (and decode on removal) that would make UCA work. I have no idea, but if such algorithms existed and were well understood, then it'd definitely make me lean towards punting language specification to v2. J > >> > >> If this works for folks I can write a proposal for the specific changes > to the spec. > >> > >> Thanks > >> -pablo > > > >
RE: [IndexedDB] Languages for collation
From: Mikeal Rogers [mailto:mikeal.rog...@gmail.com] Sent: Wednesday, August 11, 2010 11:35 PM >> Why not just use the unicode collation algorithm? >> >> Then you won't have to hint the locale. Unless I'm missing something, the UCA defines the general algorithm for collating strings but you still need to know the language in order to sort strings properly in that language. For example, in Spanish the letters "c" and "h" together (e.g. in "chau" (bye)) sort as a single letter, causing the expected sort order to be different from English where they are always two independent letters (e.g. so "chau" comes before "cuando" (when) when sorted in English, but after when sorted in Spanish). >> >> http://en.wikipedia.org/wiki/Unicode_collation_algorithm >> >> CouchDB uses some definitions around sorting complex types like arrays and >> objects but when it comes down to sorting strings it just defaults to to the >> unicode collation algorithm and all the locale's are happy. >> >> -Mikeal >> >> On Wed, Aug 11, 2010 at 11:28 PM, Pablo Castro >> wrote: >> We had some discussions about collation algorithms and such in the past, but >> I don't think we have settled on the language aspect of it. In order to have >> stores and indexes sort character-based keys in a way that is consistent >> with users' expectations we'll have to take indication in the API of what >> language we should use to collate strings. >> >> Trying to take a minimalist approach, we could add an optional parameter on >> the database open call that indicates the language to use (e.g. "en" or >> "en-UK", etc.). If the language is not specified and the database does not >> exist, then we can use the current browser/OS language to create the >> database. If not specified and database already exists, then use the one >> it's already there (this accommodates the fact that a user may be able to >> change their default language in the browser/OS after the database has been >> created using the default). If the language is specified and the database >> already exists and the specified language is not the one the database has >> then we'll throw an exception (same behavior as with "description", although >> we have that one in flight right now as well). >> >> We should probably also add a read-only attribute to the database object >> that exposes the language. >> >> If this works for folks I can write a proposal for the specific changes to >> the spec. >> >> Thanks >> -pablo
