Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 01:27:10 +0900, Tyler Close wrote: Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? Because I've yet to receive detailed feedback / proposals on CORS on what needs changing. In another thread Maciej asked you whether you would like to file the appropriate bugs and the he would do so if you did not get around to it. I have not seen much since. -- Anne van Kesteren http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 03:47:06 +0900, Maciej Stachowiak
wrote:
I kinda hate the boolean argument. I would rather have a syntax where
the intent is obvious from the source code. A boolean is not very self-
documenting. In fact I can't even remember right now whether true or
false is the value that gives you anonymous XHR. Possibilities:
- Separate AnonXMLHttpRequest constructor
- Constructor parameter takes an enum value, so you write new
XMLHttpRequest(ANON) or something like that.
- Constructor parameter takes a string value, so you write new
XMLHttpRequest("anon") or ("anonymous") or whatever.
I guess a separate constructor is the easiest way to go then. I wasn't
sure whether it was worth it as it clutters the global object some more.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: UMP / CORS: Implementor Interest
On Wed, 21 Apr 2010 03:34:42 +0900, Jonas Sicking wrote:
It looks ok to me, though somewhat lacking on details. What happens if
you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
See Web IDL.
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
See the Web IDL fragment in the specification.
I'm also wondering if the UMP guys are happy with this syntax.
I haven't gotten feedback on it so far.
There has been suggestions of changing header names. I'm not a big fan
of the current names, but if we're going to fix them, i'd rather see a
coherent strategy for all CORS headers than random spot fixes.
Does that mean you would be willing to remove support for the current
header
names? If not I'm not sure if it is worth it. But if you are I will
make a
proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
Okay.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [IndexedDB] Granting storage quotas
On 4/20/2010 5:25 PM, Jeremy Orlow wrote: It was kind of difficult to track. The basic consensus was that persistent data can and should not be deleted without explicit user approval. Hrm, I saw it as people went in with an opinion, and pretty much everyone left with the same opinion (I thought that you were the only one that was convinced by arguments, but maybe I missed something). Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 5:25 PM, Jeremy Orlow wrote: > On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher wrote: > >> On 4/20/2010 3:19 PM, Jeremy Orlow wrote: >> >>> This way of thinking is incompatible with offline web apps. If I'm >>> offline >>> and I "send" and email, it needs to stay queued up to send until I'm >>> reconnected to the internet. >>> >> I think a smart browser would include "am I offline" in it's heuristic for >> granting storage space. > > > Granting storage space is only part of the problem. > > Extrapolating from what you said, I guess I could see us keeping track of > which origins have ever been accessed offline and making sure that data is > never deleted without consulting the user. > > But, that doesn't solve this use case: something tike TiddlyWiki which > lives totally on your system and is not supposed to be synced to the cloud. > The problem is that if you used this on your desktop, which is never > offline, then the browser would not know it's precious. > > We could use the existence of an appCache manifest as a hint. I guess that > might be good enough. But then we still have the malware problem. > > >> Anyone wanting to debate whether or not the UA should be free to clean >>> up >>> "persistent storage" without asking the user should read >>> >>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 >>> and >>> the various other threads it spawned first and only re-start things if >>> they >>> have new information to add. >>> >> I read it, but I don't see a consensus formed before it died off. Am I >> missing something? >> > > It was kind of difficult to track. The basic consensus was > that persistent data can and should not be deleted without explicit user > approval. > > There was no such consensus. That was one position taken by some and not by others. > > > On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta wrote: > >> >> On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: >> >> This way of thinking is incompatible with offline web apps. If I'm >> offline and I "send" and email, it needs to stay queued up to send until I'm >> reconnected to the internet. >> >> >> I think the problem is that data loss could occur regardless of >> "guarantees". >> > > Sure, and that came up in the original giant "thread". Even if something's > in the cloud, it could be lost. So what it really comes down to is best > effort. > > Here are the classes of storage I hear you asking for: >> >> 1. temporary (no likelihood of data being being stored after session ends) >> > > I don't think this type is very interesting. The only use case is when you > have so much data that the UA might need to spill to disk. And if you're > doing that, I'd imagine you'd want to use one of the other storage types > anyway. > > >> 2. evictable (no limit per site, except global limits, eviction candidates >> chosen arbitrarily, including while application is running) >> 3. non-evictable (no eviction, but data loss possible, limited by user) >> > > These 2 are what we're talking about. >
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta wrote: > > On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: > > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > > > I think the problem is that data loss could occur regardless of > "guarantees". > > Here are the classes of storage I hear you asking for: > > 1. temporary (no likelihood of data being being stored after session ends) > 2. evictable (no limit per site, except global limits, eviction candidates > chosen arbitrarily, including while application is running) > 3. non-evictable (no eviction, but data loss possible, limited by user) > > Is this making sense? > That categorization does make sense, including the temporary. I think we're (i know i am) most interested in the distinction between evictable and non-evictable right now because the quota management and ui implications. We've introduced these storage APIs that result in files on disk, and now we want to put in some real-world storage management features. The dumbed down 5MB per origin was a stop gap measure. This is reminding me of Mike Wilson's "state handling" post about different scopes and lifetimes... http://old.nabble.com/html5-state-handling:-overview-and-extensions-td24034773.html > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 > and > the various other threads it spawned first and only re-start things if they > have new information to add. > > J > > On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta wrote: > >> As I see it, there's no such thing as "permanent" storage for Web browser >> managed data. Even if a site expresses preferences that it would like to >> keep its data resident for a long time, there cannot be a "guarantee" for >> the data to be there permanently. If applications are bound to have to deal >> with data disappearing while they are not running, we should not need to >> spec browser behavior around the notion of purgeable or permanent. >> >> It makes sense for an application, OTOH, to say that it does not need data >> to be stored on disk. IOW, create a database that is non-durable and, hence, >> kept only in memory. Such databases are required to be empty upon creation. >> They may be spilled over to disk, if implementations like to, but they will >> not be retained from session to session. >> >> Nikunj >> >> >> On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: >> >> I'd like to back up and challenge the notion of a per-site quota. >> >> In this discussion and others there is an underlying assumption that each >> site has some well defined limit that the user-agent has granted it. I doubt >> that's the best model. (Fyi: the chrome team's overly simplistic model >> whereby each site gets 5M was not chosen because its a good model, this was >> done just to proceed with building out the storage APIs independent of a >> real storage management strategy). >> >> I'd like to set aside the per-site quota assumption and explore some >> alternative models for web storage management. >> >> Some thoughts about the world we're designing for. There are an open ended >> number of sites, each of which *could* use web storage in some form. From >> that fact alone, it's impossible to come up with a quota that could be >> granted to each and every site. It seems likely that the number of sites >> that will actually require "permanent" storage is small compared to the >> number of sites that *could* make use of more "volatile" storage, to borrow >> jorlow's term, where the volatile data on disk can get scrapped by the >> user-agent as needed. Maybe a better term for that class of storage is >> "purgeable"? >> >> Maybe we should be designing for what seems to be the more common case, >> lots of sites that make use of volatile/purgeable storage. But also come up >> a means whereby the smaller number of sites that require stronger guarantees >> can express the need for more permanent storage. >> >> "What if" by default all local storage is "purgeable". A lot of quota >> issues melt away in this case since the user agent is free to reclaim >> anything at anytime. I think it'd be reasonable if the user-agent never >> asked the user anything on a per-site basis. A user-agent could warn when >> system disk space crossed thresholds and give the user an option to set >> limits on system disk space usage for webstorage as a whole. >> >> "What if" when creating local storage repositories (WebDBs or IndexedDBs >> or WebFileSystems or AppCaches) there was an optional means for the webapp >> to express "please consider this a permanent storage repository". The first >> time a site request "permanent" storage could be a reasonable time to >> interact with the user in some form, or to consult the
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 5:59 PM, Jeremy Orlow wrote: > On Tue, Apr 20, 2010 at 5:42 PM, Nikunj Mehta wrote: > >> >> On Apr 20, 2010, at 5:25 PM, Jeremy Orlow wrote: >> >> On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher wrote: >> >>> On 4/20/2010 3:19 PM, Jeremy Orlow wrote: >>> This way of thinking is incompatible with offline web apps. If I'm offline and I "send" and email, it needs to stay queued up to send until I'm reconnected to the internet. >>> I think a smart browser would include "am I offline" in it's heuristic >>> for granting storage space. >> >> >> Granting storage space is only part of the problem. >> >> Extrapolating from what you said, I guess I could see us keeping track of >> which origins have ever been accessed offline and making sure that data is >> never deleted without consulting the user. >> >> But, that doesn't solve this use case: something tike TiddlyWiki which >> lives totally on your system and is not supposed to be synced to the cloud. >> The problem is that if you used this on your desktop, which is never >> offline, then the browser would not know it's precious. >> >> We could use the existence of an appCache manifest as a hint. I guess >> that might be good enough. But then we still have the malware problem. >> >> >>> Anyone wanting to debate whether or not the UA should be free to clean up "persistent storage" without asking the user should read http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and the various other threads it spawned first and only re-start things if they have new information to add. >>> I read it, but I don't see a consensus formed before it died off. Am I >>> missing something? >>> >> >> It was kind of difficult to track. The basic consensus was >> that persistent data can and should not be deleted without explicit user >> approval. >> >> >> >> On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta >> wrote: >> >>> >>> On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: >>> >>> This way of thinking is incompatible with offline web apps. If I'm >>> offline and I "send" and email, it needs to stay queued up to send until I'm >>> reconnected to the internet. >>> >>> >>> I think the problem is that data loss could occur regardless of >>> "guarantees". >>> >> >> Sure, and that came up in the original giant "thread". Even if >> something's in the cloud, it could be lost. So what it really comes down to >> is best effort. >> >> Here are the classes of storage I hear you asking for: >>> >>> 1. temporary (no likelihood of data being being stored after session >>> ends) >>> >> >> I don't think this type is very interesting. The only use case is when >> you have so much data that the UA might need to spill to disk. And if >> you're doing that, I'd imagine you'd want to use one of the other storage >> types anyway. >> >> Oops, one thing I didn't consider is "session" as in per tab (like SessionStorage) rather than per document. I don't know if this is what you originally meant (based on your arguments, I assume it's not), in which case I'd consider this a 4th kind of storage. Now that I think about it, I'm pretty sure the enumeration of all of these types was done in some thread in the past. But I believe that's it: per document, per session/tab, caches/evictable/volatile/transient/purgable/etc, and persistient/non-evictable/etc.
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 5:42 PM, Nikunj Mehta wrote: > > On Apr 20, 2010, at 5:25 PM, Jeremy Orlow wrote: > > On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher wrote: > >> On 4/20/2010 3:19 PM, Jeremy Orlow wrote: >> >>> This way of thinking is incompatible with offline web apps. If I'm >>> offline >>> and I "send" and email, it needs to stay queued up to send until I'm >>> reconnected to the internet. >>> >> I think a smart browser would include "am I offline" in it's heuristic for >> granting storage space. > > > Granting storage space is only part of the problem. > > Extrapolating from what you said, I guess I could see us keeping track of > which origins have ever been accessed offline and making sure that data is > never deleted without consulting the user. > > But, that doesn't solve this use case: something tike TiddlyWiki which > lives totally on your system and is not supposed to be synced to the cloud. > The problem is that if you used this on your desktop, which is never > offline, then the browser would not know it's precious. > > We could use the existence of an appCache manifest as a hint. I guess that > might be good enough. But then we still have the malware problem. > > >> Anyone wanting to debate whether or not the UA should be free to clean >>> up >>> "persistent storage" without asking the user should read >>> >>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 >>> and >>> the various other threads it spawned first and only re-start things if >>> they >>> have new information to add. >>> >> I read it, but I don't see a consensus formed before it died off. Am I >> missing something? >> > > It was kind of difficult to track. The basic consensus was > that persistent data can and should not be deleted without explicit user > approval. > > > > On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta wrote: > >> >> On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: >> >> This way of thinking is incompatible with offline web apps. If I'm >> offline and I "send" and email, it needs to stay queued up to send until I'm >> reconnected to the internet. >> >> >> I think the problem is that data loss could occur regardless of >> "guarantees". >> > > Sure, and that came up in the original giant "thread". Even if something's > in the cloud, it could be lost. So what it really comes down to is best > effort. > > Here are the classes of storage I hear you asking for: >> >> 1. temporary (no likelihood of data being being stored after session ends) >> > > I don't think this type is very interesting. The only use case is when you > have so much data that the UA might need to spill to disk. And if you're > doing that, I'd imagine you'd want to use one of the other storage types > anyway. > > > This is very useful when doing B-tree manipulation such as joins and > queries. One could argue that there is no value to doing in memory > operations using a native B-tree implementation, but I don't buy that. > Why not? B-trees are a great on-disk data structure, but there are better data structures for operations completely within memory. IndexedDB does not yet support joins, so I don't see that applying either. > I have seen many uses of this with Berkeley DB. > You're really going to have to list some examples rather than saying "trust me, this is important". Net net, if we are going to define durability modes, then this one is > important. > I'm not yet convinced. :-)
Re: [IndexedDB] Granting storage quotas
On Apr 20, 2010, at 5:25 PM, Jeremy Orlow wrote: > On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher wrote: > On 4/20/2010 3:19 PM, Jeremy Orlow wrote: > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > I think a smart browser would include "am I offline" in it's heuristic for > granting storage space. > > Granting storage space is only part of the problem. > > Extrapolating from what you said, I guess I could see us keeping track of > which origins have ever been accessed offline and making sure that data is > never deleted without consulting the user. > > But, that doesn't solve this use case: something tike TiddlyWiki which lives > totally on your system and is not supposed to be synced to the cloud. The > problem is that if you used this on your desktop, which is never offline, > then the browser would not know it's precious. > > We could use the existence of an appCache manifest as a hint. I guess that > might be good enough. But then we still have the malware problem. > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 > and > the various other threads it spawned first and only re-start things if they > have new information to add. > I read it, but I don't see a consensus formed before it died off. Am I > missing something? > > It was kind of difficult to track. The basic consensus was that persistent > data can and should not be deleted without explicit user approval. > > > > On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta wrote: > > On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: > >> This way of thinking is incompatible with offline web apps. If I'm offline >> and I "send" and email, it needs to stay queued up to send until I'm >> reconnected to the internet. > > I think the problem is that data loss could occur regardless of "guarantees". > > Sure, and that came up in the original giant "thread". Even if something's > in the cloud, it could be lost. So what it really comes down to is best > effort. > > Here are the classes of storage I hear you asking for: > > 1. temporary (no likelihood of data being being stored after session ends) > > I don't think this type is very interesting. The only use case is when you > have so much data that the UA might need to spill to disk. And if you're > doing that, I'd imagine you'd want to use one of the other storage types > anyway. This is very useful when doing B-tree manipulation such as joins and queries. One could argue that there is no value to doing in memory operations using a native B-tree implementation, but I don't buy that. I have seen many uses of this with Berkeley DB. Net net, if we are going to define durability modes, then this one is important. > > 2. evictable (no limit per site, except global limits, eviction candidates > chosen arbitrarily, including while application is running) > 3. non-evictable (no eviction, but data loss possible, limited by user) > > These 2 are what we're talking about.
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 5:07 PM, Shawn Wilsher wrote: > On 4/20/2010 3:19 PM, Jeremy Orlow wrote: > >> This way of thinking is incompatible with offline web apps. If I'm >> offline >> and I "send" and email, it needs to stay queued up to send until I'm >> reconnected to the internet. >> > I think a smart browser would include "am I offline" in it's heuristic for > granting storage space. Granting storage space is only part of the problem. Extrapolating from what you said, I guess I could see us keeping track of which origins have ever been accessed offline and making sure that data is never deleted without consulting the user. But, that doesn't solve this use case: something tike TiddlyWiki which lives totally on your system and is not supposed to be synced to the cloud. The problem is that if you used this on your desktop, which is never offline, then the browser would not know it's precious. We could use the existence of an appCache manifest as a hint. I guess that might be good enough. But then we still have the malware problem. > Anyone wanting to debate whether or not the UA should be free to clean up >> "persistent storage" without asking the user should read >> >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 >> and >> the various other threads it spawned first and only re-start things if >> they >> have new information to add. >> > I read it, but I don't see a consensus formed before it died off. Am I > missing something? > It was kind of difficult to track. The basic consensus was that persistent data can and should not be deleted without explicit user approval. On Tue, Apr 20, 2010 at 5:18 PM, Nikunj Mehta wrote: > > On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: > > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > > > I think the problem is that data loss could occur regardless of > "guarantees". > Sure, and that came up in the original giant "thread". Even if something's in the cloud, it could be lost. So what it really comes down to is best effort. Here are the classes of storage I hear you asking for: > > 1. temporary (no likelihood of data being being stored after session ends) > I don't think this type is very interesting. The only use case is when you have so much data that the UA might need to spill to disk. And if you're doing that, I'd imagine you'd want to use one of the other storage types anyway. > 2. evictable (no limit per site, except global limits, eviction candidates > chosen arbitrarily, including while application is running) > 3. non-evictable (no eviction, but data loss possible, limited by user) > These 2 are what we're talking about.
Re: [IndexedDB] Granting storage quotas
Hi Michael, It would be nice if we can come up with a single mechanism for controlling the durability of local data. This mechanism could be used by IndexedDB, DataCache, WebStorage, etc. Nikunj On Apr 20, 2010, at 3:31 PM, Michael Nordman wrote: > > > On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta wrote: > As I see it, there's no such thing as "permanent" storage for Web browser > managed data. Even if a site expresses preferences that it would like to keep > its data resident for a long time, there cannot be a "guarantee" for the data > to be there permanently. If applications are bound to have to deal with data > disappearing while they are not running, we should not need to spec browser > behavior around the notion of purgeable or permanent. > > > I see a difference between a cached version of a picture you've downloaded vs > a new picture taken while on vacation by a camera built into the device and > placed into a local repository managed by the user-agent. There is only one > copy of that picture in the world. > > I'm looking for ways to make these storage APIs widely available w/o a lot of > user-prompting, but also for ways for webapps to express stronger guarantees > when needed. I think the notion of purgeable vs permanent may help reconcile > these conflicting goals. > > > It makes sense for an application, OTOH, to say that it does not need data to > be stored on disk. IOW, create a database that is non-durable and, hence, > kept only in memory. Such databases are required to be empty upon creation. > They may be spilled over to disk, if implementations like to, but they will > not be retained from session to session. > > Nikunj > > > On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: > >> I'd like to back up and challenge the notion of a per-site quota. >> >> In this discussion and others there is an underlying assumption that each >> site has some well defined limit that the user-agent has granted it. I doubt >> that's the best model. (Fyi: the chrome team's overly simplistic model >> whereby each site gets 5M was not chosen because its a good model, this was >> done just to proceed with building out the storage APIs independent of a >> real storage management strategy). >> >> I'd like to set aside the per-site quota assumption and explore some >> alternative models for web storage management. >> >> Some thoughts about the world we're designing for. There are an open ended >> number of sites, each of which *could* use web storage in some form. From >> that fact alone, it's impossible to come up with a quota that could be >> granted to each and every site. It seems likely that the number of sites >> that will actually require "permanent" storage is small compared to the >> number of sites that *could* make use of more "volatile" storage, to borrow >> jorlow's term, where the volatile data on disk can get scrapped by the >> user-agent as needed. Maybe a better term for that class of storage is >> "purgeable"? >> >> Maybe we should be designing for what seems to be the more common case, lots >> of sites that make use of volatile/purgeable storage. But also come up a >> means whereby the smaller number of sites that require stronger guarantees >> can express the need for more permanent storage. >> >> "What if" by default all local storage is "purgeable". A lot of quota issues >> melt away in this case since the user agent is free to reclaim anything at >> anytime. I think it'd be reasonable if the user-agent never asked the user >> anything on a per-site basis. A user-agent could warn when system disk space >> crossed thresholds and give the user an option to set limits on system disk >> space usage for webstorage as a whole. >> >> "What if" when creating local storage repositories (WebDBs or IndexedDBs or >> WebFileSystems or AppCaches) there was an optional means for the webapp to >> express "please consider this a permanent storage repository". The first >> time a site request "permanent" storage could be a reasonable time to >> interact with the user in some form, or to consult the user prefs about >> allowing permanent storage w/o being asked. >> >> I think ericu is baking in a distinction in between 'permanent' and >> 'temporary' in the FileSystem API he's working on. Some harmony across all >> flavors of local storage could be good. >> >> I actually think local storage management is an area where the webplatform >> has a chance to do a much better job then the desktop platforms have >> historically done. We don't need no stinking quotas ;) But we also don't >> need untold amounts of unused permanent storage littering disk drives >> needlessly around the globe (until the user gets a new system). A silly >> analogy. A computer is like a ship at sea. After years of usage, a whole >> bunch of barnacles build up on the hull and slow the vessel down. The >> webplatform to date is barnacle free in this area because t
Re: [IndexedDB] Granting storage quotas
On Apr 20, 2010, at 3:19 PM, Jeremy Orlow wrote: > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. I think the problem is that data loss could occur regardless of "guarantees". Here are the classes of storage I hear you asking for: 1. temporary (no likelihood of data being being stored after session ends) 2. evictable (no limit per site, except global limits, eviction candidates chosen arbitrarily, including while application is running) 3. non-evictable (no eviction, but data loss possible, limited by user) Is this making sense? > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 > and the various other threads it spawned first and only re-start things if > they have new information to add. > > J > > On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta wrote: > As I see it, there's no such thing as "permanent" storage for Web browser > managed data. Even if a site expresses preferences that it would like to keep > its data resident for a long time, there cannot be a "guarantee" for the data > to be there permanently. If applications are bound to have to deal with data > disappearing while they are not running, we should not need to spec browser > behavior around the notion of purgeable or permanent. > > It makes sense for an application, OTOH, to say that it does not need data to > be stored on disk. IOW, create a database that is non-durable and, hence, > kept only in memory. Such databases are required to be empty upon creation. > They may be spilled over to disk, if implementations like to, but they will > not be retained from session to session. > > Nikunj > > > On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: > >> I'd like to back up and challenge the notion of a per-site quota. >> >> In this discussion and others there is an underlying assumption that each >> site has some well defined limit that the user-agent has granted it. I doubt >> that's the best model. (Fyi: the chrome team's overly simplistic model >> whereby each site gets 5M was not chosen because its a good model, this was >> done just to proceed with building out the storage APIs independent of a >> real storage management strategy). >> >> I'd like to set aside the per-site quota assumption and explore some >> alternative models for web storage management. >> >> Some thoughts about the world we're designing for. There are an open ended >> number of sites, each of which *could* use web storage in some form. From >> that fact alone, it's impossible to come up with a quota that could be >> granted to each and every site. It seems likely that the number of sites >> that will actually require "permanent" storage is small compared to the >> number of sites that *could* make use of more "volatile" storage, to borrow >> jorlow's term, where the volatile data on disk can get scrapped by the >> user-agent as needed. Maybe a better term for that class of storage is >> "purgeable"? >> >> Maybe we should be designing for what seems to be the more common case, lots >> of sites that make use of volatile/purgeable storage. But also come up a >> means whereby the smaller number of sites that require stronger guarantees >> can express the need for more permanent storage. >> >> "What if" by default all local storage is "purgeable". A lot of quota issues >> melt away in this case since the user agent is free to reclaim anything at >> anytime. I think it'd be reasonable if the user-agent never asked the user >> anything on a per-site basis. A user-agent could warn when system disk space >> crossed thresholds and give the user an option to set limits on system disk >> space usage for webstorage as a whole. >> >> "What if" when creating local storage repositories (WebDBs or IndexedDBs or >> WebFileSystems or AppCaches) there was an optional means for the webapp to >> express "please consider this a permanent storage repository". The first >> time a site request "permanent" storage could be a reasonable time to >> interact with the user in some form, or to consult the user prefs about >> allowing permanent storage w/o being asked. >> >> I think ericu is baking in a distinction in between 'permanent' and >> 'temporary' in the FileSystem API he's working on. Some harmony across all >> flavors of local storage could be good. >> >> I actually think local storage management is an area where the webplatform >> has a chance to do a much better job then the desktop platforms have >> historically done. We don't need no stinking quotas ;) But we also don't >> need untold amounts of unused permanent storage littering disk drives >> needlessly around the globe (until the user gets a new system). A silly >>
Re: [IndexedDB] Granting storage quotas
On 4/19/2010 10:08 PM, Jeremy Orlow wrote: On Tue, Apr 13, 2010 at 3:09 AM, Mark Seaborn wrote: 2) It is too permissive because it enforces no limit on the amount of space a web app can use: A web app from example.com can create an unlimited number of puppet subdomains: aaa.example.com, bbb.example.com, etc. It can use aaa.example.com's 5Mb allocation by loading a script from aaa.example.com in an iframe and communicating with it using postMessage(). As far as I'm aware, no one (including Chromium) has a solution to at the moment. Which probably should be a cause for concern. :-) In the thread you linked to earlier, it was suggested that user agents could also factor in the top level domain into the cap (e.g. example.com only gets 50MB of space). But really, I don't see how any of this is testable in a deterministic matter, so I don't see the point in adding it to the spec. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Granting storage quotas
On 4/20/2010 3:19 PM, Jeremy Orlow wrote: This way of thinking is incompatible with offline web apps. If I'm offline and I "send" and email, it needs to stay queued up to send until I'm reconnected to the internet. I think a smart browser would include "am I offline" in it's heuristic for granting storage space. Anyone wanting to debate whether or not the UA should be free to clean up "persistent storage" without asking the user should read http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and the various other threads it spawned first and only re-start things if they have new information to add. I read it, but I don't see a consensus formed before it died off. Am I missing something? Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: FileReader question about ProgressEvent
On Tue, Apr 20, 2010 at 3:51 PM, Jian Li wrote:
> According to the spec, we will dispatch a progress event for a read method.
> But per the "Progress Events 1.0" spec, the attributes "loaded" and "total"
> are defined as "unsigned long".
> interface ProgressEvent : events::Event {
> ...
> readonly attribute unsigned long loaded;
> readonly attribute unsigned long total;
> ...
> The type "unsigned long" is not enough to represent the file size. Do we
> want to update the Progress Event spec to use "unsigned long long"? Or we
> could limit the FileReader to only read from the file with size less than
> MAX_UINT.
I think the progress events spec needs to be amended here yes. Though
one complication is that ECMAScript can't represent all values of a
unsigned long long.
Ideally webidl would define an integer type with 53 bits (which iirc
is the largest size you can precisely represent in an ECMAScript
value).
/ Jonas
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 3:19 PM, Jeremy Orlow wrote: > This way of thinking is incompatible with offline web apps. If I'm offline > and I "send" and email, it needs to stay queued up to send until I'm > reconnected to the internet. > > Anyone wanting to debate whether or not the UA should be free to clean up > "persistent storage" without asking the user should read > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and > the various other threads it spawned first and only re-start things if they > have new information to add. Indeed. Per the other thread, a relatively simple approach that keeps popping up, and which Michael raised here as well, is the idea of splitting up storage into just two basic categories: transient/purgable/cache/short-term and long-term/"permanent". These two categories represent, I believe, the most useful distinction, because these are categories that we can then translate directly into differing UA behaviors. Transient storage doesn't need a user's direct input to be used. Much like cookies, by default sites can use transient storage silently and as much as they want. However, the UA is free to put whatever limits it desires on total transient storage available, and have whatever cache eviction policies it wants in order to cull space when things start to get full. The only thing we may want to provide to the app is a way to query "probably available space". This would tell the app approximately how much space the UA estimates the app can use before risking running into problems. It is only an estimate, however. This sort of information is necessary for an app to be able to distinguish between a desktop browser with a full-sized hard drive, a mobile browser with limited space, and a device with no long-term storage. It also allows direct interaction with user preferences, so that a user may choose between the easily-understandable options of "Lots of Space", "Limited Space", and "No Space" as the default grant to webapps. Permanent storage *does* need a user's direct input. This should *not* be through a script-originated modal dialog. The best way to trigger something through user input is to use the markup designed to capture user input - s! There are various ways that this sort of thing can be usefully exposed. For things like LocalStorage and IndexedDatabase, the user would interact with a specialized that would create an appropriate storage space and fire some event. For things like FileWriter, we could instead expose an ordinary Save File dialog which would act similarly. The common thread is just that the user directly activates something on their own, and *only then* is presented with a dialog of some kind to decide on the specific options. This is the place where requesting quotas can be useful. Apps can be built to use both kinds of storage seamlessly this way. An email app, frex, can by default save drafts in temporary storage (no need to ask the user, but subject to eviction), but if the user grants it file access, it can instead save them into a directory structure on the hard drive. This sort of approach also addresses the issues brought up in the OP. An app needing a large grant can just ask the user to click on an button, which is relatively safe. Simultaneously, an evil app can't really exploit any holes in the grant procedure, because the only storage it gets automatically is implicitly both transient and subject to UA automatic controls. Worst case, a UA doesn't do anything special and the evil site just clobbers all the other temporary storage. Best case, the UA uses an intelligent eviction algorithm that makes more established data more resistant to eviction. Making this sort of distinction means, of course, that *all* currently specified storage types are transient. ~TJ
FileReader question about ProgressEvent
According to the spec, we will dispatch a progress event for a read method.
But per the "Progress Events 1.0" spec, the attributes "loaded" and "total"
are defined as "unsigned long".
interface ProgressEvent : events::Event {
...
readonly attribute unsigned long loaded;
readonly attribute unsigned long total;
...
The type "unsigned long" is not enough to represent the file size. Do we
want to update the Progress Event spec to use "unsigned long long"? Or we
could limit the FileReader to only read from the file with size less than
MAX_UINT.
Jian
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta wrote: > As I see it, there's no such thing as "permanent" storage for Web browser > managed data. Even if a site expresses preferences that it would like to > keep its data resident for a long time, there cannot be a "guarantee" for > the data to be there permanently. If applications are bound to have to deal > with data disappearing while they are not running, we should not need to > spec browser behavior around the notion of purgeable or permanent. > I see a difference between a cached version of a picture you've downloaded vs a new picture taken while on vacation by a camera built into the device and placed into a local repository managed by the user-agent. There is only one copy of that picture in the world. I'm looking for ways to make these storage APIs widely available w/o a lot of user-prompting, but also for ways for webapps to express stronger guarantees when needed. I think the notion of purgeable vs permanent may help reconcile these conflicting goals. > It makes sense for an application, OTOH, to say that it does not need data > to be stored on disk. IOW, create a database that is non-durable and, hence, > kept only in memory. Such databases are required to be empty upon creation. > They may be spilled over to disk, if implementations like to, but they will > not be retained from session to session. > > Nikunj > > > On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: > > I'd like to back up and challenge the notion of a per-site quota. > > In this discussion and others there is an underlying assumption that each > site has some well defined limit that the user-agent has granted it. I doubt > that's the best model. (Fyi: the chrome team's overly simplistic model > whereby each site gets 5M was not chosen because its a good model, this was > done just to proceed with building out the storage APIs independent of a > real storage management strategy). > > I'd like to set aside the per-site quota assumption and explore some > alternative models for web storage management. > > Some thoughts about the world we're designing for. There are an open ended > number of sites, each of which *could* use web storage in some form. From > that fact alone, it's impossible to come up with a quota that could be > granted to each and every site. It seems likely that the number of sites > that will actually require "permanent" storage is small compared to the > number of sites that *could* make use of more "volatile" storage, to borrow > jorlow's term, where the volatile data on disk can get scrapped by the > user-agent as needed. Maybe a better term for that class of storage is > "purgeable"? > > Maybe we should be designing for what seems to be the more common case, > lots of sites that make use of volatile/purgeable storage. But also come up > a means whereby the smaller number of sites that require stronger guarantees > can express the need for more permanent storage. > > "What if" by default all local storage is "purgeable". A lot of quota > issues melt away in this case since the user agent is free to reclaim > anything at anytime. I think it'd be reasonable if the user-agent never > asked the user anything on a per-site basis. A user-agent could warn when > system disk space crossed thresholds and give the user an option to set > limits on system disk space usage for webstorage as a whole. > > "What if" when creating local storage repositories (WebDBs or IndexedDBs or > WebFileSystems or AppCaches) there was an optional means for the webapp to > express "please consider this a permanent storage repository". The first > time a site request "permanent" storage could be a reasonable time to > interact with the user in some form, or to consult the user prefs about > allowing permanent storage w/o being asked. > > I think ericu is baking in a distinction in between 'permanent' and > 'temporary' in the FileSystem API he's working on. Some harmony across all > flavors of local storage could be good. > > I actually think local storage management is an area where the webplatform > has a chance to do a much better job then the desktop platforms have > historically done. We don't need no stinking quotas ;) But we also don't > need untold amounts of unused permanent storage littering disk drives > needlessly around the globe (until the user gets a new system). A silly > analogy. A computer is like a ship at sea. After years of usage, a whole > bunch of barnacles build up on the hull and slow the vessel down. The > webplatform to date is barnacle free in this area because there are no > permanent local storage facilities... lets try to make these new features > not so barnacle prone too. > > Cheers > -Michael > > On Tue, Apr 20, 2010 at 11:17 AM, Shawn Wilsher wrote: > >> On 4/20/2010 4:11 AM, Mark Seaborn wrote: >> >>> 1) It doesn't allow a web app to ask for a storage allocation up front, >>> before it starts to consume the storage. >>> >> Why does that matter? >> >
Re: [IndexedDB] Granting storage quotas
This way of thinking is incompatible with offline web apps. If I'm offline and I "send" and email, it needs to stay queued up to send until I'm reconnected to the internet. Anyone wanting to debate whether or not the UA should be free to clean up "persistent storage" without asking the user should read http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and the various other threads it spawned first and only re-start things if they have new information to add. J On Tue, Apr 20, 2010 at 3:10 PM, Nikunj Mehta wrote: > As I see it, there's no such thing as "permanent" storage for Web browser > managed data. Even if a site expresses preferences that it would like to > keep its data resident for a long time, there cannot be a "guarantee" for > the data to be there permanently. If applications are bound to have to deal > with data disappearing while they are not running, we should not need to > spec browser behavior around the notion of purgeable or permanent. > > It makes sense for an application, OTOH, to say that it does not need data > to be stored on disk. IOW, create a database that is non-durable and, hence, > kept only in memory. Such databases are required to be empty upon creation. > They may be spilled over to disk, if implementations like to, but they will > not be retained from session to session. > > Nikunj > > > On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: > > I'd like to back up and challenge the notion of a per-site quota. > > In this discussion and others there is an underlying assumption that each > site has some well defined limit that the user-agent has granted it. I doubt > that's the best model. (Fyi: the chrome team's overly simplistic model > whereby each site gets 5M was not chosen because its a good model, this was > done just to proceed with building out the storage APIs independent of a > real storage management strategy). > > I'd like to set aside the per-site quota assumption and explore some > alternative models for web storage management. > > Some thoughts about the world we're designing for. There are an open ended > number of sites, each of which *could* use web storage in some form. From > that fact alone, it's impossible to come up with a quota that could be > granted to each and every site. It seems likely that the number of sites > that will actually require "permanent" storage is small compared to the > number of sites that *could* make use of more "volatile" storage, to borrow > jorlow's term, where the volatile data on disk can get scrapped by the > user-agent as needed. Maybe a better term for that class of storage is > "purgeable"? > > Maybe we should be designing for what seems to be the more common case, > lots of sites that make use of volatile/purgeable storage. But also come up > a means whereby the smaller number of sites that require stronger guarantees > can express the need for more permanent storage. > > "What if" by default all local storage is "purgeable". A lot of quota > issues melt away in this case since the user agent is free to reclaim > anything at anytime. I think it'd be reasonable if the user-agent never > asked the user anything on a per-site basis. A user-agent could warn when > system disk space crossed thresholds and give the user an option to set > limits on system disk space usage for webstorage as a whole. > > "What if" when creating local storage repositories (WebDBs or IndexedDBs or > WebFileSystems or AppCaches) there was an optional means for the webapp to > express "please consider this a permanent storage repository". The first > time a site request "permanent" storage could be a reasonable time to > interact with the user in some form, or to consult the user prefs about > allowing permanent storage w/o being asked. > > I think ericu is baking in a distinction in between 'permanent' and > 'temporary' in the FileSystem API he's working on. Some harmony across all > flavors of local storage could be good. > > I actually think local storage management is an area where the webplatform > has a chance to do a much better job then the desktop platforms have > historically done. We don't need no stinking quotas ;) But we also don't > need untold amounts of unused permanent storage littering disk drives > needlessly around the globe (until the user gets a new system). A silly > analogy. A computer is like a ship at sea. After years of usage, a whole > bunch of barnacles build up on the hull and slow the vessel down. The > webplatform to date is barnacle free in this area because there are no > permanent local storage facilities... lets try to make these new features > not so barnacle prone too. > > Cheers > -Michael > > On Tue, Apr 20, 2010 at 11:17 AM, Shawn Wilsher wrote: > >> On 4/20/2010 4:11 AM, Mark Seaborn wrote: >> >>> 1) It doesn't allow a web app to ask for a storage allocation up front, >>> before it starts to consume the storage. >>> >> Why does that matter? >> >> >> 2) In Opera, the quo
Re: [IndexedDB] Granting storage quotas
As I see it, there's no such thing as "permanent" storage for Web browser managed data. Even if a site expresses preferences that it would like to keep its data resident for a long time, there cannot be a "guarantee" for the data to be there permanently. If applications are bound to have to deal with data disappearing while they are not running, we should not need to spec browser behavior around the notion of purgeable or permanent. It makes sense for an application, OTOH, to say that it does not need data to be stored on disk. IOW, create a database that is non-durable and, hence, kept only in memory. Such databases are required to be empty upon creation. They may be spilled over to disk, if implementations like to, but they will not be retained from session to session. Nikunj On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote: > I'd like to back up and challenge the notion of a per-site quota. > > In this discussion and others there is an underlying assumption that each > site has some well defined limit that the user-agent has granted it. I doubt > that's the best model. (Fyi: the chrome team's overly simplistic model > whereby each site gets 5M was not chosen because its a good model, this was > done just to proceed with building out the storage APIs independent of a real > storage management strategy). > > I'd like to set aside the per-site quota assumption and explore some > alternative models for web storage management. > > Some thoughts about the world we're designing for. There are an open ended > number of sites, each of which *could* use web storage in some form. From > that fact alone, it's impossible to come up with a quota that could be > granted to each and every site. It seems likely that the number of sites that > will actually require "permanent" storage is small compared to the number of > sites that *could* make use of more "volatile" storage, to borrow jorlow's > term, where the volatile data on disk can get scrapped by the user-agent as > needed. Maybe a better term for that class of storage is "purgeable"? > > Maybe we should be designing for what seems to be the more common case, lots > of sites that make use of volatile/purgeable storage. But also come up a > means whereby the smaller number of sites that require stronger guarantees > can express the need for more permanent storage. > > "What if" by default all local storage is "purgeable". A lot of quota issues > melt away in this case since the user agent is free to reclaim anything at > anytime. I think it'd be reasonable if the user-agent never asked the user > anything on a per-site basis. A user-agent could warn when system disk space > crossed thresholds and give the user an option to set limits on system disk > space usage for webstorage as a whole. > > "What if" when creating local storage repositories (WebDBs or IndexedDBs or > WebFileSystems or AppCaches) there was an optional means for the webapp to > express "please consider this a permanent storage repository". The first time > a site request "permanent" storage could be a reasonable time to interact > with the user in some form, or to consult the user prefs about allowing > permanent storage w/o being asked. > > I think ericu is baking in a distinction in between 'permanent' and > 'temporary' in the FileSystem API he's working on. Some harmony across all > flavors of local storage could be good. > > I actually think local storage management is an area where the webplatform > has a chance to do a much better job then the desktop platforms have > historically done. We don't need no stinking quotas ;) But we also don't need > untold amounts of unused permanent storage littering disk drives needlessly > around the globe (until the user gets a new system). A silly analogy. A > computer is like a ship at sea. After years of usage, a whole bunch of > barnacles build up on the hull and slow the vessel down. The webplatform to > date is barnacle free in this area because there are no permanent local > storage facilities... lets try to make these new features not so barnacle > prone too. > > Cheers > -Michael > > On Tue, Apr 20, 2010 at 11:17 AM, Shawn Wilsher wrote: > On 4/20/2010 4:11 AM, Mark Seaborn wrote: > 1) It doesn't allow a web app to ask for a storage allocation up front, > before it starts to consume the storage. > Why does that matter? > > > 2) In Opera, the quota can only be increased in multiples of about 15, so it > takes three prompts to get up into the range of gigabytes. > But there is an unlimited option, yeah? > > > 3) The web app can't choose when the question is put to the user. > 4) The web app doesn't know how much storage has been allocated, so it > doesn't know when a question will be asked. > 5) In Opera, if the user chooses "Reject", they don't get prompted again. > This means that asking the user at an appropriate time is important for the > continued functioning of the web app. P
Re: [IndexedDB] Granting storage quotas
I'd like to back up and challenge the notion of a per-site quota. In this discussion and others there is an underlying assumption that each site has some well defined limit that the user-agent has granted it. I doubt that's the best model. (Fyi: the chrome team's overly simplistic model whereby each site gets 5M was not chosen because its a good model, this was done just to proceed with building out the storage APIs independent of a real storage management strategy). I'd like to set aside the per-site quota assumption and explore some alternative models for web storage management. Some thoughts about the world we're designing for. There are an open ended number of sites, each of which *could* use web storage in some form. From that fact alone, it's impossible to come up with a quota that could be granted to each and every site. It seems likely that the number of sites that will actually require "permanent" storage is small compared to the number of sites that *could* make use of more "volatile" storage, to borrow jorlow's term, where the volatile data on disk can get scrapped by the user-agent as needed. Maybe a better term for that class of storage is "purgeable"? Maybe we should be designing for what seems to be the more common case, lots of sites that make use of volatile/purgeable storage. But also come up a means whereby the smaller number of sites that require stronger guarantees can express the need for more permanent storage. "What if" by default all local storage is "purgeable". A lot of quota issues melt away in this case since the user agent is free to reclaim anything at anytime. I think it'd be reasonable if the user-agent never asked the user anything on a per-site basis. A user-agent could warn when system disk space crossed thresholds and give the user an option to set limits on system disk space usage for webstorage as a whole. "What if" when creating local storage repositories (WebDBs or IndexedDBs or WebFileSystems or AppCaches) there was an optional means for the webapp to express "please consider this a permanent storage repository". The first time a site request "permanent" storage could be a reasonable time to interact with the user in some form, or to consult the user prefs about allowing permanent storage w/o being asked. I think ericu is baking in a distinction in between 'permanent' and 'temporary' in the FileSystem API he's working on. Some harmony across all flavors of local storage could be good. I actually think local storage management is an area where the webplatform has a chance to do a much better job then the desktop platforms have historically done. We don't need no stinking quotas ;) But we also don't need untold amounts of unused permanent storage littering disk drives needlessly around the globe (until the user gets a new system). A silly analogy. A computer is like a ship at sea. After years of usage, a whole bunch of barnacles build up on the hull and slow the vessel down. The webplatform to date is barnacle free in this area because there are no permanent local storage facilities... lets try to make these new features not so barnacle prone too. Cheers -Michael On Tue, Apr 20, 2010 at 11:17 AM, Shawn Wilsher wrote: > On 4/20/2010 4:11 AM, Mark Seaborn wrote: > >> 1) It doesn't allow a web app to ask for a storage allocation up front, >> before it starts to consume the storage. >> > Why does that matter? > > > 2) In Opera, the quota can only be increased in multiples of about 15, so >> it >> takes three prompts to get up into the range of gigabytes. >> > But there is an unlimited option, yeah? > > > 3) The web app can't choose when the question is put to the user. >> 4) The web app doesn't know how much storage has been allocated, so it >> doesn't know when a question will be asked. >> 5) In Opera, if the user chooses "Reject", they don't get prompted again. >> This means that asking the user at an appropriate time is important for >> the >> continued functioning of the web app. Prompting the user at the wrong >> time >> will interrupt them with a page-modal dialog which they might want to get >> rid of with "Reject", which would potentially break the web app by leaving >> it unable to get more storage. >> > These all feel like user-agent specific worries on how the user agent wants > to bring this to the attention of the user. > > Cheers, > > Shawn > >
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:36 AM, Jonas Sicking wrote: > On Tue, Apr 20, 2010 at 9:27 AM, Tyler Close wrote: >> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: >>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. >>> >>> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS >>> that make it more or less the same as UMP. >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > Would you be fine with "folding" UMP into CORS if more of the wording > from UMP is used in the CORS spec? > > Are the differences only editorial or are there different header > names/values as well? The differences are not only editorial. The problem is missing MUST statements in the CORS spec, governing what the user-agent does. The on-the-wire parts are nearly identical. The header names and values are consistent (or will be once CORS response header filtering is fixed). Ideally, I'd like UMP to be folded into CORS by reference rather than by value, since there are major outstanding issues against CORS that don't affect UMP. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:39 AM, Maciej Stachowiak wrote: > > On Apr 20, 2010, at 9:27 AM, Tyler Close wrote: > >> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren >> wrote: >>> >>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking >>> wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. >>> >>> Have you looked at the proposal I put in XHR2? It sets certain flags in >>> CORS >>> that make it more or less the same as UMP. >> >> Why can't it be made exactly like UMP? All of the requirements in UMP >> have been discussed at length and in great detail on this list by some >> highly qualified people. The current UMP spec reflects all of that >> discussion. By your own admission, the CORS spec has not received the >> same level of review for these features. Why hasn't CORS adopted the >> UMP solution? > > It should be made exactly like UMP, either by changing CORS, or changing > UMP, or some combination of the two. A list of differences between UMP and > CORS "anonymous mode" would be most helpful. Some of these issues are listed at the top of: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0060.html Many of the differences arise from CORS being silent about relevant issues, such as caching or received cookies, so it's hard to know what the CORS stand on these issues is. This part of the CORS spec is just not well developed yet. Since there are still major outstanding issues against other parts of the CORS spec, I still think it's a better idea to move forward with separate documents, where the CORS spec references the UMP spec for its credential-free mode. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 11:47 AM, Maciej Stachowiak wrote:
>
> On Apr 20, 2010, at 11:34 AM, Jonas Sicking wrote:
>
>> On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren
>> wrote:
>>>
>>> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking
>>> wrote:
As I've said before. I'd be interested in implementing UMP in firefox
if we can come up with a reasonable API for using it. I.e. a separate
constructor or flag or similar on XHR. This is assuming that UMP is a
reasonable subset of CORS.
>>>
>>> Have you looked at the proposal I put in XHR2? It sets certain flags in
>>> CORS
>>> that make it more or less the same as UMP. I don't really see why we
>>> would
>>> need UMP if we have that.
>>
>> It looks ok to me, though somewhat lacking on details. What happens if you
>> call
>>
>> x = new XMLHttpRequest("foopy");
>> or
>> x = new XMLHttpRequest(undefined);
>>
>>
>> You should probably define that the 'anon' argument is a boolean so
>> that the normal conversion rules automatically are applied.
>
> I kinda hate the boolean argument. I would rather have a syntax where the
> intent is obvious from the source code. A boolean is not very
> self-documenting. In fact I can't even remember right now whether true or
> false is the value that gives you anonymous XHR. Possibilities:
>
> - Separate AnonXMLHttpRequest constructor
> - Constructor parameter takes an enum value, so you write new
> XMLHttpRequest(ANON) or something like that.
> - Constructor parameter takes a string value, so you write new
> XMLHttpRequest("anon") or ("anonymous") or whatever.
>
> For any of those options (or similar variants), it would be immediately
> obvious from source what is going on.
I agree that these all are better options. I think I like the enum one
the least, especially since you'd likely have to write
x = new XMLHttpRequest(XMLHttpRequest.ANON);
which would likely result in people writing
x = new XMLHttpRequest(1);
My favorite is the separate constructor.
>> I'm also wondering if the UMP guys are happy with this syntax.
>>
There has been suggestions of changing header names. I'm not a big fan
of the current names, but if we're going to fix them, i'd rather see a
coherent strategy for all CORS headers than random spot fixes.
>>>
>>> Does that mean you would be willing to remove support for the current
>>> header
>>> names? If not I'm not sure if it is worth it. But if you are I will make
>>> a
>>> proposal.
>>
>> Yeah, the goal would definitely be to drop the old header names. We
>> probably couldn't drop them right away, but would need a phase-out
>> period. I think this would still be doable, but the longer we wait the
>> less that is going to be true.
>>
>> Also, it requires everyone to be on board with this change, including
>> webkit and Microsoft.
>
> What do we know about the current level of CORS deployments? I'd be very
> hesitant to change headers that are actively in use. It might be reasonable
> to change only some of the headers if we learn that, for example,
> "Access-Control-Allow-Origin" is the only one in common use.
>
> Also, it's hard to answer this in the hypothetical. Do we have a specific
> idea for new header names that would be really great? I'm worried that
> opening up for change will just trigger a giant bikeshed and possibly not
> result in better names in the end.
These are all good questions. I'd say the responsibility to suggest
better names lies with the people that want to change the current
names.
I think phasing out the existing header names could be done relatively
quickly. The one exception is IE which traditionally have been slower
moving as far as backwards incompatible changes goes.
I don't intend to spend a lot of time on this until someone has
suggested a new set of header names and gotten microsoft to say they
are fine with implementing them in XDR.
/ Jonas
[Bug 9563] New: The events passed to the event handlers are underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9563 Summary: The events passed to the event handlers are underspecified Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/2006/webapi/WebSimpleDB/#event-handl er OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Either the spec is missing a reference somewhere, or there is no specifying what the event objects we give to the event handlers should look like in the current spec. -- 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] Bug/enhancement requests
Let's have discussions on the mailing list. That said, let's move minor bugs such as typos and agreed decisions for applying to the spec over to the issue tracking system. HTH, Nikunj On Apr 20, 2010, at 11:52 AM, Shawn Wilsher wrote: > On 4/19/2010 11:29 PM, Nikunj Mehta wrote: >> In order to have a sane process around processing feedback and keeping track >> of progress, may I request you to please use the W3 issue tracking system >> [1], when possible? > Do you want us to do this even for issues that have not been fleshed out on > the mailing list (like API decisions)? Just trying to get an understanding > of what exactly you want bugs filed for, and what you want to happen on the > discussion list. > > Cheers, > > Shawn >
Re: [IndexedDB] Bug/enhancement requests
On 4/19/2010 11:29 PM, Nikunj Mehta wrote: In order to have a sane process around processing feedback and keeping track of progress, may I request you to please use the W3 issue tracking system [1], when possible? Do you want us to do this even for issues that have not been fleshed out on the mailing list (like API decisions)? Just trying to get an understanding of what exactly you want bugs filed for, and what you want to happen on the discussion list. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: UMP / CORS: Implementor Interest
On Apr 20, 2010, at 11:34 AM, Jonas Sicking wrote:
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren
wrote:
On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking
wrote:
As I've said before. I'd be interested in implementing UMP in
firefox
if we can come up with a reasonable API for using it. I.e. a
separate
constructor or flag or similar on XHR. This is assuming that UMP
is a
reasonable subset of CORS.
Have you looked at the proposal I put in XHR2? It sets certain
flags in CORS
that make it more or less the same as UMP. I don't really see why
we would
need UMP if we have that.
It looks ok to me, though somewhat lacking on details. What happens
if you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
I kinda hate the boolean argument. I would rather have a syntax where
the intent is obvious from the source code. A boolean is not very self-
documenting. In fact I can't even remember right now whether true or
false is the value that gives you anonymous XHR. Possibilities:
- Separate AnonXMLHttpRequest constructor
- Constructor parameter takes an enum value, so you write new
XMLHttpRequest(ANON) or something like that.
- Constructor parameter takes a string value, so you write new
XMLHttpRequest("anon") or ("anonymous") or whatever.
For any of those options (or similar variants), it would be
immediately obvious from source what is going on.
I'm also wondering if the UMP guys are happy with this syntax.
There has been suggestions of changing header names. I'm not a big
fan
of the current names, but if we're going to fix them, i'd rather
see a
coherent strategy for all CORS headers than random spot fixes.
Does that mean you would be willing to remove support for the
current header
names? If not I'm not sure if it is worth it. But if you are I will
make a
proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
What do we know about the current level of CORS deployments? I'd be
very hesitant to change headers that are actively in use. It might be
reasonable to change only some of the headers if we learn that, for
example, "Access-Control-Allow-Origin" is the only one in common use.
Also, it's hard to answer this in the hypothetical. Do we have a
specific idea for new header names that would be really great? I'm
worried that opening up for change will just trigger a giant bikeshed
and possibly not result in better names in the end.
Cheers,
Maciej
[Bug 9562] New: Opening a database with a different description is underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562 Summary: Opening a database with a different description is underspecified Product: WebAppsWG Version: unspecified Platform: All URL: http://www.mail-archive.com/public-webapps@w3.org/msg0 8084.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update the description. -- 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: UMP / CORS: Implementor Interest
On Apr 20, 2010, at 9:27 AM, Tyler Close wrote: On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: As I've said before. I'd be interested in implementing UMP in firefox if we can come up with a reasonable API for using it. I.e. a separate constructor or flag or similar on XHR. This is assuming that UMP is a reasonable subset of CORS. Have you looked at the proposal I put in XHR2? It sets certain flags in CORS that make it more or less the same as UMP. Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? It should be made exactly like UMP, either by changing CORS, or changing UMP, or some combination of the two. A list of differences between UMP and CORS "anonymous mode" would be most helpful. Regards, Maciej
Re: UMP / CORS: Implementor Interest
On Tue, Apr 20, 2010 at 9:27 AM, Tyler Close wrote: > On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: >> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: >>> >>> As I've said before. I'd be interested in implementing UMP in firefox >>> if we can come up with a reasonable API for using it. I.e. a separate >>> constructor or flag or similar on XHR. This is assuming that UMP is a >>> reasonable subset of CORS. >> >> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS >> that make it more or less the same as UMP. > > Why can't it be made exactly like UMP? All of the requirements in UMP > have been discussed at length and in great detail on this list by some > highly qualified people. The current UMP spec reflects all of that > discussion. By your own admission, the CORS spec has not received the > same level of review for these features. Why hasn't CORS adopted the > UMP solution? Would you be fine with "folding" UMP into CORS if more of the wording from UMP is used in the CORS spec? Are the differences only editorial or are there different header names/values as well? / Jonas
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote:
> On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote:
>>
>> As I've said before. I'd be interested in implementing UMP in firefox
>> if we can come up with a reasonable API for using it. I.e. a separate
>> constructor or flag or similar on XHR. This is assuming that UMP is a
>> reasonable subset of CORS.
>
> Have you looked at the proposal I put in XHR2? It sets certain flags in CORS
> that make it more or less the same as UMP. I don't really see why we would
> need UMP if we have that.
It looks ok to me, though somewhat lacking on details. What happens if you call
x = new XMLHttpRequest("foopy");
or
x = new XMLHttpRequest(undefined);
You should probably define that the 'anon' argument is a boolean so
that the normal conversion rules automatically are applied.
I'm also wondering if the UMP guys are happy with this syntax.
>> There has been suggestions of changing header names. I'm not a big fan
>> of the current names, but if we're going to fix them, i'd rather see a
>> coherent strategy for all CORS headers than random spot fixes.
>
> Does that mean you would be willing to remove support for the current header
> names? If not I'm not sure if it is worth it. But if you are I will make a
> proposal.
Yeah, the goal would definitely be to drop the old header names. We
probably couldn't drop them right away, but would need a phase-out
period. I think this would still be doable, but the longer we wait the
less that is going to be true.
Also, it requires everyone to be on board with this change, including
webkit and Microsoft.
/ Jonas
[Bug 9561] New: IDBRequest should inherit from EventTarget
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9561 Summary: IDBRequest should inherit from EventTarget Product: WebAppsWG Version: unspecified Platform: All URL: http://www.mail-archive.com/public-webapps@w3.org/msg0 7975.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSimpleDB AssignedTo: nikunj.me...@oracle.com ReportedBy: sdwi...@forerunnerdesigns.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Per discussions on the mailing list, we should have IDBRequest inherit from EventTarget [1] in addition to the two methods it currently has (onsuccess and onerror). [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget -- 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] Granting storage quotas
On 4/20/2010 4:11 AM, Mark Seaborn wrote: 1) It doesn't allow a web app to ask for a storage allocation up front, before it starts to consume the storage. Why does that matter? 2) In Opera, the quota can only be increased in multiples of about 15, so it takes three prompts to get up into the range of gigabytes. But there is an unlimited option, yeah? 3) The web app can't choose when the question is put to the user. 4) The web app doesn't know how much storage has been allocated, so it doesn't know when a question will be asked. 5) In Opera, if the user chooses "Reject", they don't get prompted again. This means that asking the user at an appropriate time is important for the continued functioning of the web app. Prompting the user at the wrong time will interrupt them with a page-modal dialog which they might want to get rid of with "Reject", which would potentially break the web app by leaving it unable to get more storage. These all feel like user-agent specific worries on how the user agent wants to bring this to the attention of the user. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: UMP / CORS: Implementor Interest
On Mon, Apr 19, 2010 at 6:47 PM, Anne van Kesteren wrote: > On Tue, 20 Apr 2010 00:38:54 +0900, Jonas Sicking wrote: >> >> As I've said before. I'd be interested in implementing UMP in firefox >> if we can come up with a reasonable API for using it. I.e. a separate >> constructor or flag or similar on XHR. This is assuming that UMP is a >> reasonable subset of CORS. > > Have you looked at the proposal I put in XHR2? It sets certain flags in CORS > that make it more or less the same as UMP. Why can't it be made exactly like UMP? All of the requirements in UMP have been discussed at length and in great detail on this list by some highly qualified people. The current UMP spec reflects all of that discussion. By your own admission, the CORS spec has not received the same level of review for these features. Why hasn't CORS adopted the UMP solution? --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Re: Request for Comments: LCWD of View Mode Media Feature; deadline 18 May 2010
Hi there, This is a comment for the 20-Apr-2010 LCWD of the VMMF spec. I would like the spec to clarify whether the view modes are mutual exclusive or not. That is currently not clear. Can I have a view mode of "windowed" and "maximized" at the same time? I guess the idea is that they are all mutual exclusive, but it would be nice to have that explicitly stated in the spec. Cheers, Kenneth On Tue, Apr 20, 2010 at 12:16 PM, Arthur Barstow wrote: > WebApps WG, CSS WG, All, > > On April 20 the WebApps WG published a Last Call Working Draft (LCWD) of the > View Mode Media Feature spec: > > http://www.w3.org/TR/2010/WD-view-mode-20100420/ > > The deadline for this LCWD's comments is 18 May 2010. > > In additions to the WebApps WG and community, we explicitly ask the CSS WG > to review this LCWD. Comments from others are welcome. > > Please send comments to: > > public-weba...@w3.org > > -Art Barstow > > > -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
Request for Comments: LCWD of View Mode Media Feature; deadline 18 May 2010
WebApps WG, CSS WG, All, On April 20 the WebApps WG published a Last Call Working Draft (LCWD) of the View Mode Media Feature spec: http://www.w3.org/TR/2010/WD-view-mode-20100420/ The deadline for this LCWD's comments is 18 May 2010. In additions to the WebApps WG and community, we explicitly ask the CSS WG to review this LCWD. Comments from others are welcome. Please send comments to: public-webapps@w3.org -Art Barstow
Re: [IndexedDB] Bug/enhancement requests
There is not really a single detailed W3C policy that's been mandated for processing spec feedback. It's basically up to each individual working group to determine the specific details for what works best for them. That said, the HTML WG has a documented Decision Policy document that outlines the process that group uses - http://dev.w3.org/html5/decision-policy/decision-policy.html WebApps WG editors could consider adapting that policy to their own processing of feedback. One nice feature of it is that it can be used for handling of comments for Last Call rounds (not just for normal Working Drafts or Editors Drafts) -- and, eventually, for generating the Disposition of Comments reports necessary for exiting from Last Call. --Mike Nikunj Mehta , 2010-04-19 23:29 -0700: > Hi folks, > > I am excited to see all the discussion lately around IndexedDB as well as the > attention it is receiving from multiple implementors. > > In order to have a sane process around processing feedback and keeping track > of progress, may I request you to please use the W3 issue tracking system > [1], when possible? > > This will greatly assist all of us in our efforts to improve IndexedDB and > track the editor's processing of your feedback. > > I am not sure what the W3C process is for processing feedback, but I will > endeavor to collect everything there and process it accordingly. > > Regards, > Nikunj > > [1] > http://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=WebSimpleDB > -- Michael(tm) Smith http://people.w3.org/mike
Re: [IndexedDB] Granting storage quotas
On Tue, Apr 13, 2010 at 4:53 PM, João Eiras wrote:
> On Tue, 13 Apr 2010 12:09:14 +0200, Mark Seaborn
> wrote:
>
> Is there any plan for involving the user in storage allocation decisions
>> for
>> IndexedDB? [1]
>>
>> For comparison, the WebStorage API [2] doesn't have any special support
>> for
>> the user to make allocation choices. My understanding is that browsers
>> have
>> a fixed storage limit per origin -- in Chromium, 5Mb per origin. The
>> problem with this model is that it is both too permissive and too
>> restrictive.
>>
>
> Not really. The user agent can ask for quota from the user when the limit
> is being hit without the webpage even having to worry about it. Opera 10.50
> does that.
>
I tried this out in Opera with a script that doubles the amount of storage
it uses on each reload [1]. I got a dialog saying:
"Web Storage Quota
foo.com wants to store data on your computer, but needs more space.
Current limit: 2.7 MB
Requested limit: 5.4 MB
[this is a dropdown, also containing:
8.1 MB
10.7 MB
21.4 MB
42.7 MB
Unlimited]
[Allow] [Reject]"
This is still too restrictive because:
1) It doesn't allow a web app to ask for a storage allocation up front,
before it starts to consume the storage.
2) In Opera, the quota can only be increased in multiples of about 15, so it
takes three prompts to get up into the range of gigabytes.
3) The web app can't choose when the question is put to the user.
4) The web app doesn't know how much storage has been allocated, so it
doesn't know when a question will be asked.
5) In Opera, if the user chooses "Reject", they don't get prompted again.
This means that asking the user at an appropriate time is important for the
continued functioning of the web app. Prompting the user at the wrong time
will interrupt them with a page-modal dialog which they might want to get
rid of with "Reject", which would potentially break the web app by leaving
it unable to get more storage.
The workaround for (1) is to write junk data into local storage in an
attempt to force the browser to produce a prompt. This is obviously
inefficient. Also, this strategy is dependent on knowing what the initial
quota is, but because of (4), a web app would have to guess based on
knowledge of particular browsers' policies.
(2) is easily addressed by providing an editable field and not just a
dropdown.
(1) and (3) would be addressed by adding a requestQuota() interface as I
suggested.
For (5), I couldn't find any options in the UI for resetting the
prompt/reject state so that Opera would prompt again. "Delete Private Data"
-> "Delete Web storage databases" did not reset the prompt/reject state.
However, by searching I found that "opera:webstorage" provides a page for
granting larger quotas and resetting the prompt/reject state.
(5) could be addressed by using a non-modal info bar, or by addressing (3).
I don't mean to pick on Opera, by the way. I think it's positive that it
does allow the quota to be increased.
Regards,
Mark
[1] Here's the page I used to test this:
You have viewed this page
an untold number of
time(s).
Space consumed:
try {
if (!localStorage.pageLoadCount) {
localStorage.pageLoadCount = 0;
localStorage.data = "x";
}
localStorage.pageLoadCount = parseInt(localStorage.pageLoadCount) + 1;
document.getElementById('count').textContent =
localStorage.pageLoadCount;
var data = localStorage.data;
data = data + data;
localStorage.data = data;
document.getElementById('bytes').textContent = data.length + " chars";
}
catch (exn) {
document.getElementById('bytes').textContent = exn;
}
[Bug 9557] New: Could we get Mouse Capture via Javascript?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Summary: Could we get Mouse Capture via Javascript? Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DOM3 Events AssignedTo: schep...@w3.org ReportedBy: warcraftthre...@sbcglobal.net QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org With the new technologies like Canvas and WebGL it would be nice to get the ability to capture the mouse much like Java does. A user-agent warning could be displayed asking for permission or something with a key to release control. I'm thinking of this mostly for games like first person shooters and RTS games in the browser or other programs where moving the mouse off the screen is a problem. So the basic functionality would be the ability to turn on mouse capture (might need another name, but whatever) then the ability to detect when a user has activated the mouse capture by agreeing to allow their mouse to be captured, a release event if the user-agent has a key to exit the mouse capture mode, and a release mouse capture event that could be triggered to allow javascript to release the mouse if it's captured. I've seen multiple WebGL people talk about needing it for their projects but no one could find where to submit suggestions relating to this. I'm hoping this is the correct place. -- 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.
