- From: Dmitry Titov <dimich@google.com>
- Date: Tue, 4 Aug 2009 11:00:11 -0700
It seems "persistent" and "preloading" aspects of the proposal are very hard to do considering security bounds of web browsing, there are scalability issues and people sometimes don't like the cost/benefit or obscurity (Netscape 6 etc). What about the "shared context with DOM access" idea which, even w/o persistency, seems to resolve some issues for apps like GMail? Like a shared worker, but with access to DOM. 1. It does not have security or "resources" issues since it's only up until the pages of the given app are up (same as shared worker) 2. It does rely on 'cooperative' pages to be opened in the same process but this is easy to implement. I mean, you can't 'guarantee' it (a page from another domain may have iframe pointing to the app and it will be in a diff. process) but any reasonable app can be easily structured in a way to get its views (pages) into a single process. 3. It would help to provide fast (meaning sub-100ms, interactively fast) UI responses necessary for the seamless operations. Persistent data storage and parsing/generating HTML (including loading all the code necessary to do that from the 'pure data') will always present challenge for sub-100ms UI actions - even in native apps it is a challenge today. Here is a typical use case: You compose a message in GMial window. Halfway through you decide to peek into another mail thread for more information. You click 'tear-off' button to "disconnect" the compose window so you can see other mail threads. Today, this opens a new window and starts loading XXX Kb of script into it. You see the progress indicator for a few seconds. This script is needed to be able to go to server and generate a proper UI from the response, as well as have all the 'controller' logic when user starts to interact with such UI. With shared context, you could just take the whole DOM subtree that forms a compose window UI and pass it, as is, into the new and empty window - with even handlers hooked into the shared context. It will just relayout and continue function. You have an 'instant' tear-off. Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090804/b4f3bb73/attachment.htm>
Received on Tuesday, 4 August 2009 11:00:11 UTC