Re: [widgets] CfC to remove openURL from Widget object; deadline August 25
On Aug 13, 2010, at 15:15 , Arthur Barstow wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. +1 -- Robin Berjon - http://berjon.com/
Re: New draft of FileSystem API posted
Hi Eric, On Jul 8, 2010, at 03:50 , Eric Uhrhane wrote: 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 there? I agree that these sound like they are conformance statements (the first one is probably enough to capture them all), which usually don't go into non-normative sections. It would be best to capture the idea somewhere intended to be normative. -- Robin Berjon - http://berjon.com/
Re: [IndexedDB] Languages for collation
On Mon, Aug 16, 2010 at 12:09 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 13, 2010 at 12:15 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow jor...@chromium.org
wrote:
On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro
pablo.cas...@microsoft.com
wrote:
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.
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 lng 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
Re: [widgets] Widgets Updates
On 14/08/2010 03:12, Bernard Traversat wrote: Should we have a more explicit way to specify and notify users that some updates may require data conversion and user data will be converted after the widget is updated? Due to the error-prone nature of such conversion, users may want to back up their data before proceeding with an update. I'm not sure I understand what you mean. User data is not stored in a widget package itself. An update to an existing widget should be able to access the storage space used by previous versions of the same widget. If data conversion is required perhaps you have a use case we could look at. Regards, Rich
Re: [IndexedDB] Avoiding reader/writer starvation
On Fri, Aug 13, 2010 at 7:30 PM, Pablo Castro pablo.cas...@microsoft.comwrote: In the context of transactions, readers using READ_ONLY and writers using READ_WRITE may block each other when starting transactions, at least for cases where the underlying implementation uses locking for isolation. Since we allow multiple readers and they can start while other readers were already running, it's possible that readers end up starving writers in a concurrent setting. It seems it would be a good idea to add some minimum guarantees to the spec that ensures some amount of fairness to concurrent activities against a given database. We could either include a loose recommendation or try to mandate a strict behavior. It seems the loose recommendation is more practical, the questions are a) is there a risk of incompatible behavior because of under-specification, and b) will we risk that some implementations will just ignore this aspect if it's specified too informally. The loose recommendation could just be a sentence in the transactions section: UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation. If we wanted to be more specific, we could go with something like this (we'd probably spell it out as rules if we decide to put this strict version in the spec): All readers can run concurrently, but once a writer tries to start a transaction we stop allowing new readers to start and queue up the writer and any subsequent reader/writer. Once the existing readers are drained the writer runs, and after that whatever is queued up next runs, which can be another writer or all the remaining readers (depending upon what came first, another writer or another reader; readers are released all simultaneously since they run concurrently). Given that not all implementations will have to deal with this and that different implementations may want to have different strategies, it seems that just having the recommendation around starvation is the best option. I agree that we should have some (non-normative?) recommendation to avoid starvation in the spec and that anything more formal would be too constraining. J
Re: [IndexedDB] Explicitly stablishing the timing of clone creation
On Mon, Aug 16, 2010 at 12:11 AM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 13, 2010 at 1:43 PM, Pablo Castro pablo.cas...@microsoft.com wrote: The spec for the asynchronous put and add methods in object store as well as update in cursors don't explicitly state when clones are created, and can even be read as if clones should be created after the function call returned, when the queued up task is executed. This leads to problems where the clone may be modified after the call to put/add/update happens. Wouldn't it be more reasonable to require implementations to always create a clone of the object before returning (i.e. synchronously) and perform the rest of the operation asynchronously? Yes. If we agree on this I'll file a bug and later follow up with some text for the spec. Please do. Agreed.
Re: [widgets] CfC to remove openURL from Widget object; deadline August 25
On Mon, 16 Aug 2010 15:37:03 +0800, Robin Berjon ro...@berjon.com wrote: On Aug 13, 2010, at 15:15 , Arthur Barstow wrote: As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. +1 Support removing it. cheers -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [widgets] Widgets Updates
On 8/16/10 2:34 AM, Rich Tibbett wrote: On 14/08/2010 03:12, Bernard Traversat wrote: Should we have a more explicit way to specify and notify users that some updates may require data conversion and user data will be converted after the widget is updated? Due to the error-prone nature of such conversion, users may want to back up their data before proceeding with an update. I'm not sure I understand what you mean. User data is not stored in a widget package itself. An update to an existing widget should be able to access the storage space used by previous versions of the same widget. If data conversion is required perhaps you have a use case we could look at. The data conversion is the use case i was referring to. We should have a more explicit way to tell the end-users upfront that by installing the new update his/her data will be converted with the potential risk of losing data and never going back to the older version. Hth, B. Regards, Rich
Re: [IndexedDB] Avoiding reader/writer starvation
On Mon, Aug 16, 2010 at 3:06 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 13, 2010 at 7:30 PM, Pablo Castro pablo.cas...@microsoft.com wrote: In the context of transactions, readers using READ_ONLY and writers using READ_WRITE may block each other when starting transactions, at least for cases where the underlying implementation uses locking for isolation. Since we allow multiple readers and they can start while other readers were already running, it's possible that readers end up starving writers in a concurrent setting. It seems it would be a good idea to add some minimum guarantees to the spec that ensures some amount of fairness to concurrent activities against a given database. We could either include a loose recommendation or try to mandate a strict behavior. It seems the loose recommendation is more practical, the questions are a) is there a risk of incompatible behavior because of under-specification, and b) will we risk that some implementations will just ignore this aspect if it's specified too informally. The loose recommendation could just be a sentence in the transactions section: UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation. If we wanted to be more specific, we could go with something like this (we'd probably spell it out as rules if we decide to put this strict version in the spec): All readers can run concurrently, but once a writer tries to start a transaction we stop allowing new readers to start and queue up the writer and any subsequent reader/writer. Once the existing readers are drained the writer runs, and after that whatever is queued up next runs, which can be another writer or all the remaining readers (depending upon what came first, another writer or another reader; readers are released all simultaneously since they run concurrently). Given that not all implementations will have to deal with this and that different implementations may want to have different strategies, it seems that just having the recommendation around starvation is the best option. I agree that we should have some (non-normative?) recommendation to avoid starvation in the spec and that anything more formal would be too constraining. Sounds good to me. Here is the strategy that we're currently using in Firefox: 1. Transactions are always executed in the order they are started. Unless they can execute in parallel. 2. Transactions are considered to be started when the first request is placed against them. So in the following code: trans1 = db.transaction([foo]); trans1.objectStore(foo).get(...).onsuccess = ...; trans2 = db.transaction([foo], READ_WRITE); trans2.objectStore(foo).put(...).onsuccess = ...; trans3 = db.transaction([foo]); trans3.objectStore(foo).get(...).onsuccess = ...; trans3 won't start until trans2 is committed. / Jonas
[Bug 10379] New: This is working
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10379 Summary: This is working Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#por ts-and-garbage-collection OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#ports-and-garbage-collection Comment: This is working Posted from: 216.239.45.4 -- 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] Languages for collation
On Mon, Aug 16, 2010 at 2:20 AM, Jeremy Orlow jor...@chromium.org wrote: 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? By check I meant talk to Ben and Shawn who actually knows how our implementation works in detail. So the result is that in our current architecture we can't support different collations for different objectStores. We can support changing collation in an existing database though. It will be a very slow operation, but it's needed to avoid forcing authors to delete an existing database and recreate a new one with a new collation. By low value I mean that no one has presented a use case that requires it. 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. That would work. So effectively this function would modify all the data in all the objectStores and indexes such that it's now sorted according to the new collation. The 'success' event is fired after all data has been updated. Any requests made after the setLanguage call will see the modified data. Is that the idea? / Jonas
Re: [IndexedDB] Languages for collation
On Mon, Aug 16, 2010 at 10:11 AM, Jeremy Orlow jor...@chromium.org wrote: 2 additional questions: What standard will define the language codes and the associated collation algorithm? And what's the behavior for an implementation that doesn't support that particular language? Very good questions. Are there specifications for this stuff elsewhere? / Jonas
[Bug 10381] New: [IndexedDB] Structured clones should be created synchronously
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10381 Summary: [IndexedDB] Structured clones should be created synchronously Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 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 The spec for the asynchronous put and add methods in object store as well as update in cursors don't explicitly state when clones are created, and can even be read as if clones should be created after the function call returned, when the queued up task is executed. This leads to problems where the clone may be modified after the call to put/add/update happens. Spec needs to be updated to indicate that the actual creation of the clone should happen synchronously while the put/add/update method is running, so the state of the object used to perform the database operation is as it was at the time the call was made, regardless of the timing of the actual execution of the method, timing of the callbacks, etc. Related discussion thread here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0501.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.
[Bug 10382] New: [IndexedDB] Note on avoiding reader/writer starvation
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10382 Summary: [IndexedDB] Note on avoiding reader/writer starvation Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 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 Since in locking-based implementations it's going to be relatively easy to get into a situation where readers starve writers when working concurrently, we should have a note in the transactions section that encourages implementations to have explicit mechanisms to avoid starvation. We don't want to be too prescriptive, perhaps simply this statement: UAs need to ensure a reasonable level of fairness across readers and writers to prevent starvation. For reference, we discussed this here: http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0504.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.responseBlob and BlobWriter [nee FileWriter]
On Mon, Aug 16, 2010 at 7:05 PM, Michael Nordman micha...@google.com wrote: Hi All, I'm interested in adding support for XHR.responseBlob to webkit and chrome. It sounds like we have a general consensus to add two new members to the XmlHttpRequest interface: attribute boolean asBlob; // at least for the sake of discussion, calling it that for now readonly attribute Blob responseBlob; Another name option could be 'downloadAsBlob'. Personally, I like 'asBlob' for its brevity and its naming similarity to 'withCredentials'. Looks like the semantics of when its valid to call setRequestHeaders also applies setting the asBlob attribute; after open() but before send() has been called. An attempt to set the value at some inappropriate time should throw an INVALID_STATE exception. Also the asBlob attribute value should probably be reset to 'false' upon return from open(), again similar to how the request headers are cleared out upon return from open(). Anne, have you been following this discussion, wdyt? Michael Sounds good, though I think we let asBlob act is more like withCredentials and not get reset upon open(). Thus it can also be settable before open() as well. / Jonas
[Bug 10379] This is working
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10379 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@opera.com Resolution||INVALID -- 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.
