Re: [whatwg] createImageData should take unsigned long
On Mon, 24 Aug 2009, Philip Jägenstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML extension for system idle detection.
On Aug 29, 2009, at 00:47, David Bennett wrote: There currently is no way to detect the system idle state in the browser. This makes it difficult to deal with any sort of chat room or instant messaging client inside the browser since the idle will always be incorrect. How could such a notification be abused? The first abuse use case I can think of is throttling Web Workers-based botnet computation to be less detectable by the user (i.e. taking over the user's compute resources while the user isn't experiencing the slowdown). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] createImageData should take unsigned long
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Aug 2009, Philip Jägenstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). I get the impression this has all been discussed before. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I don't doubt that high DPI screens will happen, but when it does browsers are more likely to provide an extra flag like getImageData(..., useDevicePixels) or another opt-in method in order to stay compatible with existing content. Another option for the page author is simply creating a 1000x1000 canvas and setting its CSS width/height to 100x100 (assuming the CSS pixel:device pixel ratio can be found via script). In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/223 Firefox: log: ctx.createImageData(-1.1,1) = [Exception... log: ctx.createImageData(-1,1) = [Exception... log: ctx.createImageData(-0.1,1) = [Exception... log: ctx.createImageData(0,1) = [Exception... log: ctx.createImageData(0.1,1) = [Exception... log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 Safari/Chrome: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = 1x1 log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 2x1 My interpretation of the spec: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = INDEX_SIZE_ERR log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 If the spec doesn't say to round rather than ceil, we're bound to have subtle compatibility bugs on this. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 clarifications on ValidityState?
On Tue, 25 Aug 2009, Alex Vincent wrote: I read this paragraph (from section 4.10.15.3) as self-contradicting: The validationMessage attribute must return the empty string if the element is not a candidate for constraint validation or if it is one but it satisfies its constraints; otherwise, it must return a suitably localized message that the user agent would show the user if this were the only form with a validity constraint problem. If the element is suffering from a custom error, then the custom validity error message should be present in the return value. Specifically, the last sentence contradicts the rest of the paragraph. If there is a custom error, but the element is not a candidate for constraint validation, should the validationMessage attribute be empty, or should the custom validity error message be present in the return value? You can't have both. Fixed. Also, I noticed the readonly attribute for input elements overrides constraint validation, per section 4.10.4.2.3 - but the readonly attribute has no meaning for several input types (section 4.10.4, the big table after the IDL). For checkboxes, radio buttons, file uploads, image inputs, submit, reset and ordinary button types for the input element, readonly has no other effect. Please advise - I'm currently working on a patch for Gecko code which implements this. If the attribute doesn't apply, the text in that section is irrelevant. Does that help? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 clarifications on ValidityState?
On Tue, 25 Aug 2009, Peter Kasting wrote: [...] However, I'm not sure why elements which are barred from constraint validation (fieldset, output) have a setCustomValidity() method; perhaps so that authors could blindly iterate over all form-associated elements and call this method? Yes, that's exactly it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] object behavior
On Tue, 25 Aug 2009, Andrew Oakley wrote: Ian Hickson wrote: I'm not sure exactly what change you mean. The spec already has some of Gecko's behaviour (in particular the special-casing of certain MIME types to enable sniffing), are there other changes you think we should include? Boris Zbarsky wrote (near the top of this thread): If the type attribute was set to something that parsed as a MIME type, and if that type would be handled by a plug-in (that is, we have a plug-in to handle it, and have no other method for handling it), then use the type attribute's type instead of the header type. So if we had a type attribute of application/x-shockwave-flash, and a Content-Type header of image/png we would use the flash plugin. Following the HTML5 spec we would use the image renderer. Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this something you're forced into for compatibility? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML extension for system idle detection.
On Aug 29, 2009, at 00:47, David Bennett wrote: There currently is no way to detect the system idle state in the browser. Henri Sivonen wrote: How could such a notification be abused? The first abuse use case I can think of is throttling Web Workers-based botnet computation to be less detectable by the user (i.e. taking over the user's compute resources while the user isn't experiencing the slowdown). True, but this could probably be implemented to a largely equivalent degree using the techniques currently employed by sites in lieu of a dedicated API to know when the user is idle. I agree that an event model would be a good idea. Having a straightforward way to disable wasteful bandwidth usage when the user becomes idle is a good thing. Still, being able to check the idle state without events could be useful for some code, say a periodical executer that checks the idle state prior to doing it's work. If events are the only interface a developer would have to implement their own state keeping. One issue: Is the user idle when the tab is in the background, when the browser is in the background, or when the user is away from the machine? These are all distinct cases of different levels of idleness, and it's largely depended on the use case which kind of idleness makes sense for a particular application. .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Web Storage: apparent contradiction in spec
On Tue, 25 Aug 2009, Jens Alfke wrote: I've just noticed an apparent self-contradiction in the Web Storage spec (24 August draft). Section 4.3 states: Data stored in local storage areas should be considered potentially user-critical. It is expected that Web applications will use the local storage areas for storing user-written documents. Section 6.1 states: User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies. These statements are contradictory, because cookies don't store user-critical data such as documents. The user model of cookies is that they're conveniences (at best) for keeping you logged into a site or remembering preferences like font-size, so deleting them is no more than an inconvenience. If local storage is presented to the user as being cookies, then a user may delete it without understanding the consequences. Potential result: I was having trouble logging into FooDocs.com, so my friend suggested I delete the cookies for that site. After that I could log in, but now the document I was working on this morning has lost all the changes I made! How do I get them back? I suggest that the sub-section Treating persistent storage as cookies of section 6.1 be removed. We can't treat cookies and persistent storage differently, because otherwise we'll expose users to cookie resurrection attacks. Maintaining the user's expectations of privacy is critical. So I've removed the text that says that local storage could be user-critical. On Tue, 25 Aug 2009, Brady Eidson wrote: One key advantage of LocalStorage and Databases over cookies is that they *do* have a predictable, persistent lifetime, and the browser is *not* allowed to prune them at will. I haven't changed this. On Tue, 25 Aug 2009, Brady Eidson wrote: LocalStorage is quite clearly modeled after Flash's LocalStorage Actually I don't think I'd heard of Flash's LocalStorage at the time that localStorage (then globalStorage) was first specced. On Wed, 26 Aug 2009, Michael Nordman wrote: * Can an individual key,value pair for an origin be removed from local storage while leaving other local data in place? * Can an individual Database be deleted for an origin while leaving other local data in place? * Can an individual Manifest be deleted for an origin while leaving other local data in place? * Or should an origin's data be subject to all-or-none eviction. I would prefer to see the spec clarify questions along those lines. That would be useful. The spec leaves all of this up to the UA. It discourages unprompted eviction, but at the end of the day, as has been pointed out, there are limits to what can be guaranteed. On Wed, 26 Aug 2009, Peter Kasting wrote: That's not the proposed mandate. The proposed mandate is thou shalt not discard successfully-written data without explicit user action, which seems implementable to me. Note that this doesn't make claims like the hard drive will not fail, and it doesn't claim that the UA is required to allow the app to write whatever data it wants in the first place. That's more or less what the spec says, but it uses should which allows UAs to violate this in extreme cases (like abuse being detected, or running out of disk space, or whatnot). On Wed, 26 Aug 2009, Michael Nordman wrote: What seems inevitable are vista-like prompts to allow something (or prods to delete something) seemingly unrelated to a user's interaction with a site... please, oh please, lets avoid making that part of the web platform. I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If push comes to shove, the system could suggest cleaning up one of these 'blessed' sites if inactivity for an extended period was noticed. But for the overwhelming number of sites in a users browsing history, its a different matter. If the storage APIs are just available for use, no questions asked making the storage just go away, no questions asked, is symmetrical. Blessing involves asking questions... making it go away does too. UAs can do this, yes. On Wed, 26 Aug 2009, Jens Alfke wrote: If this is out-of-spec and browser-dependent, there won't be a good way for an app to request that blessing; it'll be something the user has to know to do, otherwise their data can get lost. That seems dangerous. In most systems user data loss is just about the worst-case scenario of what could go wrong, and you try to prevent it at all costs. In-band systems can be abused, out-of-band systems can be hard to discover. I don't know which is worse. We had bb type=makeapp for a while (an in-band system), but we removed it due to implementor feedback. My suggestion to have separate 'important' and 'cache' local storage areas would provide such a mechanism in a
Re: [whatwg] object behavior
On Mon, 31 Aug 2009 11:08:16 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 25 Aug 2009, Andrew Oakley wrote: Ian Hickson wrote: I'm not sure exactly what change you mean. The spec already has some of Gecko's behaviour (in particular the special-casing of certain MIME types to enable sniffing), are there other changes you think we should include? Boris Zbarsky wrote (near the top of this thread): If the type attribute was set to something that parsed as a MIME type, and if that type would be handled by a plug-in (that is, we have a plug-in to handle it, and have no other method for handling it), then use the type attribute's type instead of the header type. So if we had a type attribute of application/x-shockwave-flash, and a Content-Type header of image/png we would use the flash plugin. Following the HTML5 spec we would use the image renderer. Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this something you're forced into for compatibility? Opera prefers HTTP Content-Type over object type and we see some compatibility issues due to this. Examples that fail in Opera: http://www.antena3videos.com/ http://gamepod.hu/hir/ilyen_lett_a_terminator_salvation_es_a_bionic_comm.html -- Ola P. Kleiven, Core Compatibility, Opera Software
Re: [whatwg] createImageData should take unsigned long
On Mon, Aug 31, 2009 at 1:55 AM, Philip Jägenstedt phil...@opera.comwrote: I get the impression this has all been discussed before. It has. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I agree, but Ian doesn't. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] createImageData should take unsigned long
Philip Jägenstedt wrote: In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: Firefox: Just to be clear, the Firefox code for this predates the spec text. I would assume so does Webkit's. Once we're actually trying to implement the spec, we'll probably comment if we think it makes no sense or isn't clear... ;) -Boris
Re: [whatwg] object behavior
Ian Hickson wrote: On Tue, 25 Aug 2009, Andrew Oakley wrote: So if we had a type attribute of application/x-shockwave-flash, and a Content-Type header of image/png we would use the flash plugin. Following the HTML5 spec we would use the image renderer. Ah, yes, that's intentional (doing otherwise violates HTTP1.1). Is this something you're forced into for compatibility? Yes. Initially we implemented preferring the HTTP content-type header to the type attribute in https://bugzilla.mozilla.org/show_bug.cgi?id=1156. This caused a variety of compatibility issues: 1) Various sites serving plug-in data as text/plain or application/octet-stream. This was resolved by using the regular is this text actually binary? sniffer and dispatching based on type hint (in practice the type attribute at the time, but see below) if we have sniffed binary or application/octet-stream. See https://bugzilla.mozilla.org/show_bug.cgi?id=389677, which lists two sites that hit this. See https://bugzilla.mozilla.org/show_bug.cgi?id=390891 for another example of this problem. 2) A number of sites, including for example all the Apple keynote videos, just plain served plug-ins with the wrong server-provided MIME type which was not either text/plain or application/octet-stream. See https://bugzilla.mozilla.org/show_bug.cgi?id=395110 (and https://bugzilla.mozilla.org/show_bug.cgi?id=416480, https://bugzilla.mozilla.org/show_bug.cgi?id=414310, https://bugzilla.mozilla.org/show_bug.cgi?id=416867). Note that we did some debugging here and found that Opera had the same compatibility issues we did on the Apple videos; Safari did not because it was mapping a limited set of ActiveX classids to its internal MIME type dispatch and thus using the outer object, not the inner one. As a result of this issue, we introduced our current behavior of preferring @type if it's a type we handle via a plug-in. 3) A number of sites not only send a bogus server-provided type (e.g. application/octet-stream) but also use a bogus type attribute (specifically, application/plugin-mimetype; I suspect this is a relic of Netscape's devedge documentation using that as an example placeholder). See https://bugzilla.mozilla.org/show_bug.cgi?id=393756. The URI extension is used to get the type to really use in those cases in Gecko... If desired, I could probably dig through and figure out the exact conditions that trigger this case. -Boris P.S. For embed things are different but still quite interesting, of course... In particular, one has to use the URI extension there, not just the @type.
Re: [whatwg] Text areas with pattern attributes?
On Sun, Aug 30, 2009 at 10:42 PM, Jonas Sickingjo...@sicking.cc wrote: The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. input type=text also can't contain newlines. Of course, another solution would be to allow input type=text to change rendering to be that of a textarea, and teach the world to migrate from textarea to input type=text. That would seem more semantically correct. I actually think it's reasonable to argue that there's a meaningful difference between a field designed to contain a single value, like a username or social security number, and a field designed to contain free-form text. I don't think things like autocomplete (or associated features like datalist) really make any sense for textareas, for example. Some browsers also spell-check textareas by default and not input type=text, and so on. Of course, by this logic, authors should use still textarea or something for one-line free-form text inputs, like the subject field of an e-mail form. But there are styling issues that would have to be overcome for that to work.
Re: [whatwg] first script and impersonating other pages - pushState(url)
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be fleshed out some?
Section 6.1.5 Groupings of browsing contexts
says:
| Each unit of related similar-origin browsing
| contexts can have a first script which is used to
| obtain, amongst other things, the script's base
| URL to resolve relative URLs used in scripts
| running in that unit of related similar-origin
| browsing contexts. Initially, there is no first
| script.
Does this implicitly say that this set of browsing
contexts should never execute script in parallel?
No, that is implied by the event loop mechanism.
http://www.whatwg.org/specs/web-apps/current-work/#event-loops
Ah thanks, that made it clear. 6.1.5 might get a little
easier to understand if some text mentioned the shared
event loop for this set of browsing contexts, or linked
to 6.5.4.
/pages/page1.html:
script src=/scripts/script1.js
*1 button onclick=func1();
/scripts/script1.js:
function func1() { ... }
*2 func1();
What is regarded as *first script* in these two
calls to func1() ?
*1: the implicitly generated event handler wrapper
in /pages/page1.html ?
*2: /scripts/script1.js
Yes.
[...]
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision this to be structured?
Something like this? :
/pages/section1/thing1:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
Per *1 in the first example, wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
Best regards
Mike
Re: [whatwg] Global Script proposal.
Ian Hickson wrote: Given that all frames in a browsing context have to be on the same thread, regardless of domain, then unless we put all the browsing contexts on the same thread, we can't guarantee that all frames from the same domain across all browsing contexts will be on the same thread. Right, the GlobalScript proposal would cause an additional vector that enlarges the sets of related similar-origin browsing contexts, ie making more browsing contexts share event loop. But there are already a number of relationships that cause this, so can we really say that having one more is not possible? As an application developer I wouldn't have any problem with knowing up-front that my application would share thread with the other instances (pages) of my application if I use the GlobalScipt feature. (And has been mentioned, it wouldn't be a forced requirement.) @Dmitry: as an implementor, do you find problems with having a loaded page change event loop and thread, or is that just about swapping around data structures? What I'm thinking about is that if swapping is possible, then every page can start on its own thread, and then only swap over to the shared thread for that unit of related similar-origin browsing contexts if referencing a GlobalScript. (If swapping is not possible, then every page would have to try to join the thread for its origin at load time, to be prepared for GlobalScript sharing, and that would probably pull together more browsing contexts than desired into shared threds...) [...] Granted, programmers today don't want to use threads -- but, well, tough. All indications are that that's what the programming model of the next few decades is going to be; now is the time to move that way. We shouldn't be adding features that actually move us back to the single-threaded world. FWIW, I don't see the GlobalScript proposal as something that wants to avoid multi-threading. Though, with JavaScript's shared nothing approach between threads, single-threading is a side-effect of having live access (no intermediate serializing/cloning) to shared data. If there was multi-threaded access to data (you could say there already is with cookies and the storage mutex) I'm sure the GlobalScript proposal could be tailored to take advantage of that. Best regards Mike
Re: [whatwg] Storage mutex feedback
Jonas Sicking wrote: On Sat, Aug 29, 2009 at 10:06 PM, Ian Hicksoni...@hixie.ch wrote: Upon further consideration I've renamed getStorageUpdates() to yieldForStorageUpdates(). I really liked Darin's (?) suggestion of allowStorageUpdates as that seems to exactly describe the intended use of the function. We no longer prevent other page from updating the storage. Quite nice. One little nit is that it could be interpreted as allowing oneself's updates, while it is really about allowing other's updates. allowOtherStorageUpdates? (not so nice, but... ;-) Is there a preference for having the name indicate that we are finishing our own transaction, ie myStorageUpdatesAreNowComplete endStorageUpdates finishStorageUpdates commitStorageUpdates flushStorageUpdates saveStorageUpdates or should it indicate that others are now welcome to do their stuff, such as in: otherPagesStorageUpdatesAreNowWelcome allow(Other)StorageUpdates enable(Other)StorageUpdates ? Best regards Mike
Re: [whatwg] Global Script proposal.
(Grabbing from the end...) On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote: implementation experience before specifying it. But I really don't think it is the direction we should be taking the platform in. Granted, programmers today don't want to use threads -- but, well, tough. All indications are that that's what the programming model of the next few decades is going to be; now is the time to move that way. We shouldn't be adding features that actually move us back to the single-threaded world. Shared workers aren't analogous to a multithreaded programming model. They're a multiple-single-threaded-process model. It makes a difference. The former is familiar to many programmers. The latter is much less common. In general, your arguments seem to fall into three categories. (Apologies if I'm misrepresenting you by paraphrasing. My intent is not to argue against a straw man, but to actually address your concerns.) - People should be writing multi-threaded web apps. - UI code can be a small shim, so code sharing can be accomplished through shared workers. - The async model isn't really that tough. For the first, I would argue that the web should progress much like desktop apps. Computationally intensive algorithms will be done in a background thread, but all UI interaction will continue to be done on one thread. This is how desktop apps work. Scalability is accomplished by putting different apps on different cores, not by requiring each application view to run in its own thread. The application itself can decide how best to take advantage of multiple cores, balancing coding complexity against performance. This is how I'd like to see web apps work. Sharing data should be separate from splitting across cores. If an app needs to push computation to a worker thread, that facility is available, but it should be up to the app. (Of course, computationally intensive desktop applications have access to a shared heap, which would make shared workers much more attractive.) For the last two, I don't believe that they can be true simultaneously. I know that some consider the asynchronous interaction with workers to be a blocker problem, but I don't really understand why. We already have to have asynchronous communication with the server, which holds the roster data structure, and so on. What difference does it make if instead of talking to the server, you talk to a worker? It is true that XHRs to the server are async. If shared workers simply replace the server, then it's true, programming that way is exactly what people are used to. However, under that model pages that access the shared worker have all the complex code that they have today. If the shared worker replaces a server, then the worker is adding code to the client, not replacing it. For the UI to be a simple shim, shared workers have to replace more than just the server. They have to encompass the entire data model of the application. Pushing the async line from network I/O up to the data layer of the app is a huge change. I am unaware of any programming frameworks that work this way. It's not just that this is a difficult way to program, it's entirely new. You have said previously that having to rewrite Gmail is not justification for a feature, and I agree. However, since this is a totally different programming model, I find it unlikely that weekend coding projects will start off taking advantage of shared workers in a way that will maximize code reuse. Since almost all web apps start as weekend coding projects, by the time they get big enough to require code sharing, synchronous access to the data model from the UI will be endemic to the app, and it will require a rewrite. It seems to me that having shared workers as the only mechanism for code sharing is going to require a rewrite of nearly every web app, even those written in the future. (It's possible that frameworks will evolve to encourage async programming to the data model like they currently do to the network, but they will all require a rewrite before that happens.) Again, use a shared worker. The UI side of things can be quite dumb, with data pushed to it from a shared worker. Finally, I don't think the UI can ever be a simple shim. There's a long list of things that have to be in the UI: complex widget rendering, UI effects, event handling, etc. Popular frameworks like jQuery have huge amounts of code dedicated to UI programming. It's not possible to push this code to a shared worker. Every render process will have to have its own copy. Especially if the shared worker is more than just a local cache for the server, the UI layer will always be complex. Michael
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote: We can't treat cookies and persistent storage differently, because otherwise we'll expose users to cookie resurrection attacks. Maintaining the user's expectations of privacy is critical. The fact that local storage can be used as a type of super-cookie doesn't mean the two are the same thing. Yes, obviously if I give a website permission to put 50MB of stuff on my disk, it can use 1k of that as a type of cookie if it wants. That's just one of many reasons why user agents should require user approval for letting a domain access local storage. That does not mean that the Delete Cookies menu command should also delete local storage. Users often delete cookies to resolve login issues (I've had to do this with Google websites several times). Conflating the two can lead to disasters like I told you to delete my COOKIES! Not my EMAIL DRAFTS that I was trying to log in to send! So I've removed the text that says that local storage could be user- critical. That's going to come as a shock to developers who were planning to use it for user-created data (whether drafts of content to be pushed to the cloud, or strictly-local documents.) Without this, the safe usage of local storage diminishes to a download cache. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote: Yes, this is pretty disconcerting since there's been OVERWHELMING support for LocalStorage being treated as user-critical on this thread. The spec says basically what you want except that it uses should. It seems like UAs and authors would both be satisfied with this; I don't expect any UA vendor to wantonly discard local storage data. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 11:18 AM, Peter Kasting pkast...@google.com wrote: On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.orgwrote: Yes, this is pretty disconcerting since there's been OVERWHELMING support for LocalStorage being treated as user-critical on this thread. The spec says basically what you want except that it uses should. It seems like UAs and authors would both be satisfied with this; I don't expect any UA vendor to wantonly discard local storage data. If some platforms don't treat local storage as sacred, it's unlikely web developers are going to program one version for flash/whatever and one version for local storage on browsers that meet their requirements. Especially since the only way you could treat these differently is by user agent detection which has historically been a bad thing for the web.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 31, 2009, at 11:18 AM, Peter Kasting wrote: The spec says basically what you want except that it uses should. It seems like UAs and authors would both be satisfied with this; I don't expect any UA vendor to wantonly discard local storage data. By encouraging the UI to treat local storage as a type of cookie, the spec is contributing to user confusion that can lead to the type of data loss that I described in my previous message. Since user data loss is one of the very worst things any program can do to a user, I'd like the spec to encourage UAs to take a bit more care with local storage. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote: Again, the spec now says in 4.3: User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. The only stronger statement you could get would be by changing this to a must. It's not clear to me that that is going to result in any practical difference on the part of implementations or author perception. If you combine that statement with section 6.1's User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies, then the result is that, when the user requests to delete cookies from a site, the UA will also delete that site's local storage. That is exactly the behavior I am concerned about. This sounds like you are either completely ignoring, or disagreeing with, my claim that UAs aren't going to be flippant about this data. If UA's shouldn't treat the data lightly, then I would prefer to see a statement to that effect in the spec, such as the one that was just deleted. Local storage is a significant change from the browser's current data model, and I think that (no offense) browser developers are not used to taking care of user-critical data for longer than the duration of a DOM tree or POST request. It's a change in perspective. Coming as I do from a client-software world, it's actually an eye-opener to me that this is even controversial. —Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
Jens Alfke wrote: Local storage is a significant change from the browser's current data model, and I think that (no offense) browser developers are not used to taking care of user-critical data for longer than the duration of a DOM tree or POST request. It's a change in perspective. Coming as I do from a client-software world, it's actually an eye-opener to me that this is even controversial. It's controversial because, no offense, browser developers don't trust the website author, nor should the users. At least to a first approximation. This is a critical difference from client software, for better or worse. We could restrict local storage to explicitly trusted sites and then not treat it as cookies; would that be preferable? It might be. Alternately, it could be treated like cookies except for explicitly trusted sites... or something. -Boris
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 11:50 AM, Jens Alfke s...@google.com wrote: On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote: Again, the spec now says in 4.3: User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. The only stronger statement you could get would be by changing this to a must. It's not clear to me that that is going to result in any practical difference on the part of implementations or author perception. If you combine that statement with section 6.1's User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies, then the result is that, when the user requests to delete cookies from a site, the UA will also delete that site's local storage. That is *exactly* the behavior I am concerned about. That's not true. You're misinterpreting a statement about the granularity of control users should have as one about what terminology a UA should use. The spec already recommends a bunch of things about what users should be shown w.r.t. Local Storage, such as how much space a site is using, so it's clear that a UA that wants to comply with this should is going to need to construct UI that doesn't just use the word cookies everywhere but actually presents the data as here's your locally stored data for this site with local storage content enumerated. Users won't be given a prompt that says clear cookies that, confusingly, clears more than cookies; they'll be given a prompt like clear all locally stored data. It seems like you're convinced that UAs won't create UI users can understand, and so you're trying to make the spec mandate what you think will be comprehensible for users. IMO this is not only out-of-scope but pointless, as UAs are going to do what they want anyway. The spec is already pretty clear in telling UAs not to be casual about things, I don't think you're going to change what actually gets implemented by demanding more. This sounds like you are either completely ignoring, or disagreeing with, my claim that UAs aren't going to be flippant about this data. If UA's shouldn't treat the data lightly, then I would prefer to see a statement to that effect in the spec, such as the one that was just deleted. The sentence I quoted in 4.3 says _exactly_ that UAs should not treat data lightly. I think that (no offense) browser developers are not used to taking care of user-critical data for longer than the duration of a DOM tree or POST request. This kind of generalization is just silly. See e.g. saved passwords, extensions, stored browsing history, persistent settings, etc. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 6:11 AM, Ian Hicksoni...@hixie.ch wrote: We can't treat cookies and persistent storage differently, because otherwise we'll expose users to cookie resurrection attacks. Maintaining the user's expectations of privacy is critical. By that reasoning we can't treat cookies differently from the HTTP cache (ETag) or history (URIs with session IDs), I think. I don't know of any UAs that expire history/cookie/cache in sync to avoid correlations -- if it's even possible to do so -- and I don't think I've seen any bugs asking Firefox to do so. Mike
Re: [whatwg] Issues with Web Sockets API
04.08.2009, в 16:47, Ian Hickson написал(а): I've added support for redirects. While I was at it I also added support for authentication. Reading the authentication part of the latest draft, I had several comments: 9. If the client has any authentication information ... that would be relevant to a resource accessed over HTTP, if /secure/ is false, or HTTPS, if it is true, on host /host/, port /port/, with /resource name/ as the path (and possibly query parameters), then HTTP headers that would be appropriate for that information should be sent at this point. [RFC2616] [RFC2109] [RFC2965] I'm not sure how this part translates into actual behavior. What if there are several sets of credentials already known to the client, for example? Also, what if the client has already performed digest authentication with several nonce values? Is this meant to mimic some behavior that existing clients have for HTTP already? If /code/, interpreted as ASCII, is 401, then let /mode/ be _authenticate_. Otherwise, fail the Web Socket connection and abort these steps. 407 (proxy authenticate) also likely needs to be supported. - If the entry's name is www-authenticate Obtain credentials in a manner consistent with the requirements for handling the |WWW- Authenticate| header in HTTP, and then close the connection (if the server has not already done so) Some authentication schemes (e.g. NTLM) work on connection basis, so I don't think that closing the connection right after receiving a challenge can work with them. - WBR, Alexey Proskuryakov
Re: [whatwg] Web Storage: apparent contradiction in spec
On Aug 31, 2009, at 11:58 AM, Boris Zbarsky wrote: It's controversial because, no offense, browser developers don't trust the website author, nor should the users. At least to a first approximation. Over on another thread of this list we've already been talking about the need to get the user's permission before a site can use [more than a certain minimum of] local storage. So that implies the user expressing a degree of trust in the site, at least enough trust to let it use a sliver of her hard disk. I agree that if an app is just storing a few kbytes of local storage without the user's informed consent, that's just the moral equivalent of a cookie and ought to be treated as such. We could restrict local storage to explicitly trusted sites and then not treat it as cookies; would that be preferable? It might be. That would be fine. The problem is that this seems to require an API change to allow the site to distinguish between persistent storage I'm just using quietly as a cookie, and persistent storage I want to be able to store larger amounts of possibly user-critical data in. —Jens
Re: [whatwg] Global Script proposal.
On Sat, Aug 29, 2009 at 5:40 PM, Ian Hicksoni...@hixie.ch wrote: Furthermore, consider performance going forward. CPUs have pretty much gotten as fast as they're getting -- all further progress is going to be in making multithreaded applications that use as many CPUs as possible. We should actively moving away from single-threaded designs towards multithreaded designs. A shared global script is firmly in the old way of doing things, and won't scale going forward. Multi-threaded or multi-process, at least. Most web developers are quite familiar with multi-process development, where each process has a single flow of control, since that's what the browser/server interaction is. The multiple server-side processes that end up involved over the course of the user's interaction do need to share state with each other, and preserving blocking semantics for accessing such state makes the programs much simpler to reason about given today's programming languages. Is that shared state not what the Global Script Object would provide? If the synchronization overhead of manipulating it becomes undesirable to an app developer for performance reasons, they can use a worker with local state and an event mechanism or some such; that's largely what people do on the server side as well. Granted, programmers today don't want to use threads -- but, well, tough. All indications are that that's what the programming model of the next few decades is going to be; now is the time to move that way. We shouldn't be adding features that actually move us back to the single-threaded world. I disagree that explicit use of threads is the programming model of the next few decades. We are seeing more and more developers eschew shared-heap threads in favour of other techniques (f.e., task queues) that adapt better to varying system resources and allow simpler decomposition of the programming tasks. Apple's Grand Central Dispatch appears to be in this vein, though I confess I haven't analyzed it in any significant way yet. Mike
Re: [whatwg] Web Storage: apparent contradiction in spec
Quoting Ian Hickson i...@hixie.ch: On Tue, 25 Aug 2009, Jens Alfke wrote: Potential result: I was having trouble logging into FooDocs.com, so my friend suggested I delete the cookies for that site. After that I could log in, but now the document I was working on this morning has lost all the changes I made! How do I get them back? I suggest that the sub-section Treating persistent storage as cookies of section 6.1 be removed. We can't treat cookies and persistent storage differently, because otherwise we'll expose users to cookie resurrection attacks. Maintaining the user's expectations of privacy is critical. I think the paragraph under treating persistent storage as cookies should simply be removed. The remainder of that section already does an adequate job of explaining the privacy implications of persistent storage. The UI should be entirely at the discretion of the browser vendor since it involves a variety of tradeoffs, with the optimum solution depending on the anticipated user base of the browser. Placing spec requirements simply limits the abilities of browser vendors to find innovative solutions to the problem. In addition, since there is no interoperability requirement here, using RFC 2119 language seems inappropriate; especially since the justification given is rather weak (this might encourage users?) and not supported by any evidence. As to what browser vendors should actually _do_, it seems to me that the user's expectations of privacy is actually an illusion in this case; all the bad stuff that can be done with persistent storage can already be done using a variety of techniques. Trying to fix up this one case seems like closing the stable door after the horse has bolted. Therefore the delete local storage when you delete cookies model seems flawed, particularly as it can lead to the type of problem that Jens described above. On a slightly different topic, it is unclear what the relationship between the statement in section 4.3 User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user and the statement in section 6.1 User agents may automatically delete stored data after a period of time. is supposed to be. Does the latter count as a security reason?
Re: [whatwg] Orientation event in Firefox
+1, I like this approach for its simplicity and familiarity. As part of fleshing out, there are probably a few small but key additions that would greatly increase effectiveness: - update frequency (knowing the sample rate is crucial for even the most trivial DSP operations such as filtering) - units (convention is in units of 'g', i.e 9.81 m/s^2) - magnetometer in addition to accelerometer (for heading) Dave On Mon, Aug 24, 2009 at 4:39 AM, Doug Turner doug.tur...@gmail.com wrote: I posted some thoughts and a strawman for orientation in Firefox: http://dougt.org/wordpress/2009/08/orientation/ Regards, Doug Turner -- Sent from Wandsworth, Greater London, United Kingdom
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 2:01 PM, Jens Alfkes...@google.com wrote: The fact that local storage can be used as a type of super-cookie doesn't mean the two are the same thing. Yes, obviously if I give a website permission to put 50MB of stuff on my disk, it can use 1k of that as a type of cookie if it wants. That's just one of many reasons why user agents should require user approval for letting a domain access local storage. I was under the impression that the idea was that this wouldn't be necessary. Sites should be free to use localStorage as they use cookies, transparently without annoying the user with spammed pop-ups. Does any browser currently require user approval for localStorage by default, or plan to? That does not mean that the Delete Cookies menu command should also delete local storage. Users often delete cookies to resolve login issues (I've had to do this with Google websites several times). Conflating the two can lead to disasters like I told you to delete my COOKIES! Not my EMAIL DRAFTS that I was trying to log in to send! I entirely agree with this, as a user. Browsers should expose the option to clear cookies and localStorage separately. Currently Chrome's Clear Browsing Data has a separate checkboxes for browsing history, download history, cache, cookies, saved passwords, and saved form data. I'd expect it to add another checkbox for localStorage, not change cookies to cookies and localStorage. Although in any event, I'm not sure what good UI would be to say This might destroy valuable data, but probably not most of it, and whether it destroys the particular bit of data you're thinking of really depends on if the app happens to store it locally or on its servers, and if on its servers, whether it's pushed out this data yet or not. On Mon, Aug 31, 2009 at 2:36 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: Outlawing persistent storage in HTML5 as a privacy mechanism does *nothing* for privacy. There are numerous methods, Flash LocalStorage in particular, that can and will be used to achieve what we developers want. These methods will be *harder* for the end-user to monitor and control, and result in privacy violations being *easier*. What you see as a reasonable step to protect privacy, we see as an admonition that we'd better get used to Flash, because it's here to stay. I don't think that the ones using Flash LocalStorage to track users will ever switch to a standards-based solution. Anything implemented by the browser vendors will allow users to easily clear it, which defeats their goal. What HTML 5 needs to do is supplant Flash's *site-critical* functions. If Flash is relegated to only things like tracking methods, it would be feasible for it to just not be installed, and users wouldn't care. Do site-critical Flash apps (i.e., ones where the user would say the site is broken if they didn't work) often rely heavily on localStorage persistence?
Re: [whatwg] HTML extension for system idle detection.
On Mon, Aug 31, 2009 at 2:49 AM, Max Romantschuk m...@romantschuk.fi wrote: On Aug 29, 2009, at 00:47, David Bennett wrote: There currently is no way to detect the system idle state in the browser. Henri Sivonen wrote: How could such a notification be abused? The first abuse use case I can think of is throttling Web Workers-based botnet computation to be less detectable by the user (i.e. taking over the user's compute resources while the user isn't experiencing the slowdown). True, but this could probably be implemented to a largely equivalent degree using the techniques currently employed by sites in lieu of a dedicated API to know when the user is idle. True, although they can do this to some degree already as has already been pointed out. It could also be useful for apps like s...@home to run something in the browser when the user is idle as well. I agree that an event model would be a good idea. Having a straightforward way to disable wasteful bandwidth usage when the user becomes idle is a good thing. Still, being able to check the idle state without events could be useful for some code, say a periodical executer that checks the idle state prior to doing it's work. If events are the only interface a developer would have to implement their own state keeping. The problem with events is that it would end up being a defined idle time set for the entire browser, if I am thinking of how the suggestion was to implement it. I think this would be limiting, some entities would have different requirements on idleness. One issue: Is the user idle when the tab is in the background, when the browser is in the background, or when the user is away from the machine? These are all distinct cases of different levels of idleness, and it's largely depended on the use case which kind of idleness makes sense for a particular application. True. I was looking specifically at system idle, which is when the user is completely away from the machine and not when the task is backgrounded or minimized. Detecting this is probably different to idle, since you could be idle and also be in the foreground or minimized. Thanks! David.
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 6:08 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Mon, Aug 31, 2009 at 2:36 PM, Tab Atkins Jr.jackalm...@gmail.com wrote: Outlawing persistent storage in HTML5 as a privacy mechanism does *nothing* for privacy. There are numerous methods, Flash LocalStorage in particular, that can and will be used to achieve what we developers want. These methods will be *harder* for the end-user to monitor and control, and result in privacy violations being *easier*. What you see as a reasonable step to protect privacy, we see as an admonition that we'd better get used to Flash, because it's here to stay. I don't think that the ones using Flash LocalStorage to track users will ever switch to a standards-based solution. Anything implemented by the browser vendors will allow users to easily clear it, which defeats their goal. What HTML 5 needs to do is supplant Flash's *site-critical* functions. If Flash is relegated to only things like tracking methods, it would be feasible for it to just not be installed, and users wouldn't care. Do site-critical Flash apps (i.e., ones where the user would say the site is broken if they didn't work) often rely heavily on localStorage persistence? Sure, the ones using it for tracking that care *that much* will use other solutions anyway. But people who just want some persistent storage as part of their app, because it's useful to their users, will use the browser-native solution if it works. If LocalStorage is explicitly supposed to be as ephemeral of cookies, though, that will push people towards stuff like Flash LocalStorage instead. I think a lot of people weren't that aware of Flash LocalStorage, but more will be now that we're talking about it. ~TJ
Re: [whatwg] createImageData should take unsigned long
On Mon, Aug 31, 2009 at 11:06 PM, Anne van Kesteren ann...@opera.comwrote: Once we get huge screens and lots of processing power people can just blow up the canvas grid and then scale it down with CSS. Works just as well and makes the data more portable. I think we can do better than that. It's fine to use high-dpi backing store automatically for canvas in general. ImageData is the only situation where it matters if there's more than one device pixel per CSS pixel, and authors should be able to opt into taking advantage of that fact, but not be exposed to it by default, IMHO. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] HTML extension for system idle detection.
This would be a nice addition... seems like an event plus a read-only
property on the 'window' object could work.
window.idleState;
window.onidlestatechange = function(e) {...}
On Fri, Aug 28, 2009 at 3:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 28, 2009 at 2:47 PM, David Bennettd...@google.com wrote:
SUMMARY
There currently is no way to detect the system idle state in the browser.
This makes it difficult to deal with any sort of chat room or instant
messaging client inside the browser since the idle will always be
incorrect.
USE CASE
Any instant messaging client, or any client that requires user presence,
will use this to keep track of the users idle state. Currently the idle
state of a user inside a browser tell tend to be incorrect, and this
leads
to problems with people being unable to rely on the available status of a
user. Without this information it is difficult to do a full featured and
reliable instant messaging client inside the browser since this makes the
users' status somewhat unreliable.
Lots of social networking sites and other sites centered around user
interactions on the net keep track of the users idle state for enabling
interactions with people that are currently online, this would be
especially
useful for interactive online gaming.
A process that would like to do some heavy duty processing, like
s...@home,
could use the system idle detection to enable the processing only when
the
user is idle and enable it to not interfere with or degrade their normal
browsing experience.
WORK AROUNDS
The idle state of the user is currently detected by looking at the brower
window and detecting the last activity time for the window. This is
inaccurate since if the user is not looking at the page the state will be
incorrect and means that the idle time is set to longer than would be
desirable so there is also a window in which the user is actually idle
but
it has not yet been detected.
PROPOSAL
I propose an api which takes in a timeout for idle, the user agent calls
the
callback when the state changes. Active-idle, Active-away, idle-away,
idle-active, away-active.
The idle times are all specified in seconds, the handler will be called
when
the idle state changes with two arguments and then any user specified
arguments. The two arguments are the idle state and the idle time, the
idle
time should be the length of time the system is currently idle for and
the
state should be one of idle, active or locked (screen saver). The
handler
can be specified as a handler or as a string.
Not explicitly specified, and thus intentionally left to the UA, include:
* The minimum time the system must be idle before the UA will report it
[1]
* Any jitter intentionally added to the idle times reported [1]
* The granularity of the times reported (e.g. a UA may round them to
multiples of 15 seconds)
[NoInterfaceObject, ImplementedOn=Window] interface WindowTimers {
// timers
long setSystemIdleCallback(in TimeoutHandler handler, in long
idleTimeoutSec);
long setSystemIdleCallback(in TimeoutHandler handler, in
long idleTimeoutSec, arguments...);
long setSystemIdleCallback(in DOMString code, in long idleTimeoutSec);
long setSystemIdleCallback(in DOMString code, in long idleTimeoutSec, in
DOMString language);
void clearSystemIdleCallback(in long handle);
// Returns the current system idle state.
int systemIdleState();
[Callback=FunctionOnly, NoInterfaceObject]
interface TimeoutHandler {
void handleEvent(idleState, idleTime, [Variadic] in any args);
};
Where idleState is one of:
idleState : active = 1, idle = 2, away = 3
Away is defined as locked/screen saver enabled or any other system
mechanism
that is defined as away.
This is based on the setTimeout api at
http://www.w3.org/TR/html5/no.html
ALTERNATIVES
This could be made simple an event listener, where the browser itself
keeps
track of the length of time that is considered idle and fires an event
when
the state changes.
setSystemIdleCallback(in IdleHandler handler)
The downside to this is that it would mean all components on the browser
would share the same idle time, which would reduce the ability of
components
to choose the most efficent idle time for their use case. Some IM
clients
might require the user to be there within a very short of period of time
to
increase the likelyhood of finding a person. It would also not let the
components let the user choose their idle time.
The upside to this proposal is it would be a lot simpler.
REFERENCES
1] There is research showing that it is possible to detemine a users key
strokes and which keys they are actually typeing by using millisecond
accuracy idle time information. This is the reason this spec emphasises
the
jitter and granularity aspects of the idle detection.
Re: [whatwg] HTML extension for system idle detection.
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.com wrote: This would be my inclination as well. I'm not entirely convinced that every web app should define their own idle timeout is such desirable behavior that we should build our API around it by forcing every caller to specify their idle timeout - having a standard event that's fired with an exposed state for apps that need it seems like a cleaner approach. The trouble with this is it doesn't allow any experimentation on the part of the app/entity to figure out what is the best idle time for it's purposes. In terms of chat it might be that a 3 minute or 5 minute idle time works best in terms of people's attention. For something like watching a video perhaps a 15 minute idle would be a better length of time, or for an online game a longer idle time is probably useful before being signed out. Different purposes have different requirements for the idle time so it makes sense to allow them to specify the different timeouts. Thanks, David.
