Re: [whatwg] SharedWorkers and the name parameter
I agree. Moreover, since a shared worker identified by a given name cannot be navigated elsewhere, the name isn't all that synonymous with other usages of names (e.g., window.open). At the very least, it would seem helpful to scope the name to the URL to avoid the name conflict issue. -Darin On Mon, Aug 17, 2009 at 3:53 PM, Michael Nordman micha...@google.comwrote: What purpose the the 'name' serve? Just seems uncessary to have the notion of 'named' workers. They need to be identified. The url, including the fragment part, could serve that purpse just fine without a seperate 'name'. The 'name' is not enough to identify the worker, url,name is the identifier. Can the 'name' be used independently of the 'url' in any way? * From within a shared worker context, it is exposed in the global scope. This could inform the work about what 'mode' to run. The location including the fragment is also exposed within a shared worker context, the fragment part could just as well serve this 'modalility' purpose. * From the outside, it has to be provided as part of the identifier to create or connect to an shared worker. And there are awkward error conditions arising when a worker with 'name' already exists for a different 'url'. The awkward error conditions would be eliminated if id == url. * Is 'name' visible to the web developer any place besides those two? On Mon, Aug 17, 2009 at 2:44 PM, Mike Shaver mike.sha...@gmail.comwrote: On Sat, Aug 15, 2009 at 8:29 PM, Jim Jewettjimjjew...@gmail.com wrote: Currently, SharedWorkers accept both a url parameter and a name parameter - the purpose is to let pages run multiple SharedWorkers using the same script resource without having to load separate resources from the server. [ request that name be scoped to the URL, rather than the entire origin, because not all parts of example.com can easily co-ordinate.] Would there be a problem with using URL fragments to distinguish the workers? Instead of: new SharedWorker(url.js, name); Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); The normal semantics of fragments should prevent the repeated server fetch. I don't think that it's very natural for the name to be derived from the URL that way. Ignoring that we're not really identifying a fragment, it seems much less self-documenting than a name parameter. I would certainly expect, from reading that syntax, for the #part to be calling out a sub-script (property or function or some such) rather than changing how the SharedWorker referencing it is named! Mike
Re: [whatwg] Proposal to drag virtual file out of browser
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model, so
client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike Wilson
_
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jian Li
Sent: den 18 augusti 2009 03:03
To: whatwg@lists.whatwg.org
Subject: [whatwg] Proposal to drag virtual file out of browser
SUMMARY
The HTML 5 spec defines the event-based drag-and-drop mechanism that could
cross the browser boundary. If a draggable element contains a URL, dragging
it out of the browser will only copy the URL value. However, in some
scenarios, we really want to download the data file from the specified URL,
instead of copying the value. Here we propose a way to allow dragging a
virtual file denoted by an URL out of the browser boundary.
USE CASES
In order to download the attachment from an Internet mail application, the
user will have to click the attachment link and a save dialog will pop up
to let the user select the destination folder. This will normally involves
multiple clicks. Native application, like Outlook, can let the user drag
attachments directly into the destination place, i.e. desktop, which is
really convenient.
WORKAROUNDS
Currently there is no direct support in HTML 5 to support such dragging of
the virtual file. To work around this, a plugin with such capability has to
be installed and used.
PROPOSAL
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should be
parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should be
downloaded and provided to the target application.
For example, here's how one can create a draggable image that results in a
file when dragged:
var dragTarget = document.createElement(img);
dragTarget.src = http://example.com/example-attachment.gif;;
document.body.insertBefore(dragTarget, document.body.firstChild);
dragTarget.addEventListener(dragstart, function(event) {
event.dataTransfer.setData(DownloadURL,
http://example.com/example-download-attachment;);
}, false);
Traditionally allowing the non-image file to be dragged out of the browser
is considered bad. The main danger here is that the user might unknowingly
drag a file that will auto-execute. To address this issue, the browser needs
to mark the dragged file to indicate that it is coming from the Internet.
With this zone marker, the user will be prompted with a security warning
dialog when the dropped file is launched. If a specific platform does not
support zone identifier marker, this feature should be turned off by
default.
We should consider allowing only http and https typed URL in the associated
data for the DownloadURL format. Should we further restrict the download
URL to the same origin?
If the filename is provided in the Content-Disposition header, it should
always be used. Otherwise, it is up to the browser to decide how the
filename is generated from the URL. But once it is chosen, it cannot be
changed.
The drag-and-drop feedback might be decorated with the filename and the
domain from which the file is downloaded. However, the real filename might
be only available when we initiate the download and get back the response
header. To address this, we can download the response header after the drag
is initiated and then update the feedback image based on the filename
retrieved from the Content-Disposition header. This might not be possible
for certain platform because changing the drag meta-data might not be
allowed.
Re: [whatwg] Proposal to drag virtual file out of browser
Also, would it be possible to hook browser-produced data into this model,
so client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
You could also extend the File API to allow for user created instances of
FileData objects. This would be comparable to Java's Blob and Clob API.
Each blob could represent either a local file, http file, ftp file, in
memory data or lazy client-generated data. This is all unknown to the target
and it's very extensible.
Of course you could also create a data URL but you'd have to base64 encode
it and keep the whole file in memory.
The key to having a blob API is the lazy nature of it. Of course a blob
would only be living as long as the source document is still able to
generate the content on-demand.
(Here's some semi-relevant info on this pattern in the context of
DDDhttp://blog.calyptus.eu/seb/2009/03/large-object-storage-for-nhibernate-and-ddd-part-1-blobs-clobs-and-xlobs/
.)
I'm not sure I like this though because the complexity involved compared to
a DownloadURL-format. But there is a need to be able to do this with
client-generated data as well.
Sebastian Markbåge
On Tue, Aug 18, 2009 at 10:31 AM, Mike Wilson mike...@hotmail.com wrote:
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model,
so client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike Wilson
--
*From:* whatwg-boun...@lists.whatwg.org [mailto:
whatwg-boun...@lists.whatwg.org] *On Behalf Of *Jian Li
*Sent:* den 18 augusti 2009 03:03
*To:* whatwg@lists.whatwg.org
*Subject:* [whatwg] Proposal to drag virtual file out of browser
SUMMARY
The HTML 5 spec defines the event-based drag-and-drop mechanism that could
cross the browser boundary. If a draggable element contains a URL, dragging
it out of the browser will only copy the URL value. However, in some
scenarios, we really want to download the data file from the specified URL,
instead of copying the value. Here we propose a way to allow dragging a
virtual file denoted by an URL out of the browser boundary.
USE CASES
In order to download the attachment from an Internet mail application, the
user will have to click the attachment link and a save dialog will pop up
to let the user select the destination folder. This will normally involves
multiple clicks. Native application, like Outlook, can let the user drag
attachments directly into the destination place, i.e. desktop, which is
really convenient.
WORKAROUNDS
Currently there is no direct support in HTML 5 to support such dragging of
the virtual file. To work around this, a plugin with such capability has to
be installed and used.
PROPOSAL
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should be
parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should be
downloaded and provided to the target application.
For example, here's how one can create a draggable image that results in a
file when dragged:
var dragTarget = document.createElement(img);
dragTarget.src = http://example.com/example-attachment.gif;;
document.body.insertBefore(dragTarget, document.body.firstChild);
dragTarget.addEventListener(dragstart, function(event) {
event.dataTransfer.setData(DownloadURL,
http://example.com/example-download-attachment;);
}, false);
Traditionally allowing the non-image file to be dragged out of the
browser is considered bad. The main danger here is that the user might
unknowingly drag a file that will auto-execute. To address this issue, the
browser needs to mark the dragged file to indicate that it is coming from
the Internet. With this zone marker, the user will be prompted with a
security warning dialog when the dropped file is launched. If a specific
platform does not support zone identifier marker, this feature should be
turned off by default.
We should consider allowing only http and https typed URL in the associated
data for the DownloadURL format. Should we further restrict the download
URL to the same origin?
If the filename is provided in the Content-Disposition header, it should
always be used. Otherwise, it is up to the browser to decide how the
filename is generated from the URL. But once it is chosen, it cannot be
changed.
The drag-and-drop feedback might be decorated with the filename and the
domain from which the file is downloaded. However, the real filename might
be only available when we initiate the download and get back the response
header. To address this, we can download the response header after the drag
is initiated and then update the feedback image based on the filename
retrieved from the
Re: [whatwg] Spec comments, section 4.8
On Mon, Aug 17, 2009 at 8:27 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: In 4.8.10.5: There are some Unicode characters (U+231B? an hourglass?) here that are showing up as white boxes for me at the beginning of some of the list elements. Their purpose is described later in 4.8.10.5 Loading the media resource at step 20: (Steps in synchronous sections are marked with ⌛.) and noted again in 6.5.4.2 Processing model at step 4: Note: Steps in synchronous sections are marked with ⌛. but the potential for confusion could be further mitigated with an earlier reference to their purpose... perhaps in 4.8.10.5 Loading the media resource at step 9 with an addition to this phrase: This algorithm is always invoked synchronously, that instead reads something like: This algorithm is always invoked synchronously (see steps marked with ⌛.), HTTP partial range requests sounds odd to me, and partial range is redundant. Maybe just HTTP range requests? The HTTP spec uses range retrieval requests. I suspect this type of phrasing is born of human desire to shorten technical jargon into more familiar terms for frequent usage. My examination of the terminology most commonly used in RFC 2616 (related to what Ian's s trying to convey) suggests (to me) this simple change: HTTP partial content range requests In 4.8.10.10: If the attribute is absent, then the user agent should avoid making a user interface available that could conflict with an author-provided user interface. User agents may make the following features available, however, even when the attribute is absent: User agents may provide controls to affect playback of the media resource (e.g. play, pause, seeking, and volume controls), but such features should not interfere with the page's normal rendering. For example, such features could be exposed in the media element's context menu. This doesn't make a lot of sense to me. I would have expected a list of features after the first quoted paragraph, but instead there's another paragraph that partially repeats the content of the first paragraph. It reads like it originally said something different, and then something was chopped out and not patched up properly. My reading of those paragraphs (two pairs of sentences) suggests (to me) that some _do_ share purpose (unobtrusive implemetation) or target (for _whose_ sake) but each seems to make sense (to me): Sentence #1 Recommends unobtrusive implementation of UI features (for author's sake). Sentence #2 Permits override of boolean attribute for implementation of UI features. (for UA's sake) Sentence #3 Recommends unobtrusive implementation of UI features (for client's sake). Sentence #4 Illustrates how implementation of UI features can be both unobtrusive and avoid interrupting page rendering. (for UA's sake) --- Perhaps a simple clarification could be effected by changing: may make the following features available to something like: may make the features in this subsection available In 4.8.10.12: play and playing have confusingly similar names. I see (only) the unavoidable shared similarity of description (common to this _Dispatched when..._ column) which Ian currently addresses through word variations such as begun vs. started): play Event Playback has begun. playingEvent Playback has started. In combination with the additional information shown in their respective _Preconditions_ columns, there shouldn't be too much confusion by the consumer. It doesn't seem any different than: load vs. loadend _or_ seeking vs. seeked -- -- -- -- ô¿ô¬ K e V i N /¯\
[whatwg] EDITORIAL - Suggested typographical corrections
--- --- Suggested typographical corrections for: HTML 5 Draft Standard (Aug. 18, 06:49:15 AM EDT) --- --- Example: [S]UBSTITUTE//correct//incorrect// - - (reason for correction) --- --- 4.4.3 The nav element that are targetted at users S//targeted//targetted// - - (typo) --- 4.8.1 The figure element img src=promblem-packed-action.png alt=ROUGH COPY! Promblem-Packed Action! S//problem//promblem// - - (typo) S//Problem//Promblem// - - (typo) --- 4.8.10.6 Offsets into the media resource even if the underling media data has S//underlying//underling// - - (typo) --- 4.8.10.7 The ready states as the current playback position can never advanced in this case. S//advance//advanced// - - (typo) --- 4.10.6 The select element fire a simple event tgat bubbles S//that//tgat// - - (typo) --- 4.10.10 The textarea element fire a simple event that bubbls called S//bubbles//bubbls// - - (typo) --- 5.4.1 General identifying or refering to the data defined S//referring//refering// - - (typo) --- 5.4.2 vCard should have dix digits each S//six//dix// - - (typo) --- 5.4.2 vCard (i.e., LAT LON ordering), in decimal degress. S//degrees//degress// - - (typo) --- - 5.4.3 vEvent should have dix digits each S//six//dix// - - (typo) --- 5.4.3 vEvent (i.e., LAT LON ordering), in decimal degress. S//degrees//degress// - - (typo) --- - 5.4.4.1 Examples an embedded image entitiled My Pond, S//entitled//entitiled// - - (typo) --- 5.5 Converting HTML to other formats upon which the vocaulary-specific conversions S//vocabulary//vocaulary// - - (typo) --- 5.5.4 iCalendar consisting of a type type, a value value, and optinally an annotation, S//optionally//optinally// - - (typo) --- 5.5.5 Atom Let id be a user-agent defined undereferencable yet globally unique absolute URL. S//undereferenceable//undereferencable// - - (typo) --- 5.5.5 Atom value of the href attribute of the first such a ot area element, S//of//ot// - - (typo) --- 6.4 Origin for URLs that identify the same resouce, S//resource//resouce// - - (typo) --- 6.6 Timers The WindowTimers interfaceadds to the Window interface S//interface adds//interfaceadds// - - (typo) --- 6.12.3.9 Link type license titleExampl Pictures: Kissat/title S//Example Pictures//Exampl Pictures// - - (typo) --- 7.6 The accesskey attribute assign a key combination of its chosing as the element's assigned access key S//choosing//chosing// - - (typo) ---
[whatwg] EDITORIAL - Suggested grammatical corrections
---
---
Suggested grammatical corrections for:
HTML 5
Draft Standard
(Aug. 18, 06:53:04 AM EDT)
---
---
Example:
[S]UBSTITUTE//correct//incorrect// - - (reason for correction)
---
---
2.1.5 Plugins
it is expected to be user-agent- and platform-specific.
S//platform- and user-agent specific//user-agent- and
platform-specific// - - (match usage of user-agent specific
throughout)
---
2.4.5 Dates and times
Implementators are therefore encouraged to carefully examine any date
parsing libraries
S//Implementors//Implementators// - - (match usage throughout document)
---
2.6 Fetching resources
resource is to be obtained using a idempotent action
S//an idempotent//a idempotent// - - (using an ... action)
---
3.2.4 DOM tree accessors
A call to document.getElementById('example').getElementsByClassName('bbb
ccc ') would return the same thing.
S//('bbb ccc')//('bbb ccc ')// - - (unintended whitespace assumed)
---
4.3.1 The script element
The exact processing details for these attributes is described below.
S//are described//is described// - - (details ... are described)
---
4.8.11.1.9 Text
property-independent stylesheet syntax
S//style sheet//stylesheet// - - (match usage throughout document
when not used as keyword/element name)
---
4.8.14.2 Processing model
some other non-visible text, in a user-agent-defined fashion...
S//user-agent defined//user-agent-defined// - - (match usage
throughout document)
---
4.10.4 The input element
table is non-normative and summarises which content attributes
S//summarizes//summarises// - - (match the only other instance of usage)
---
4.10.4.1.17 Radio Button state
Either neither a nor b have a form owner, or they both have one and
it is the same for both.
S//Either a and b both have no form owner//Either neither a nor b have
a form owner// - - (rewrote either neither)
---
6.1.2 Auxiliary browsing contexts
contexts that are related to a top level browsing context
S//top-level browsing//top level browsing// - - (match usage
throughout document)
---
9.2 Parsing HTML documents
report more than one parse error condition if more than one parse
error conditions exist in the document.
S//condition exists//conditions exist// - - (report more than one
/ more than one ... exists)
---
11.4.1 Introduction
snippets below set the 'binding' property to a user-agent-defined value
S//user-agent defined//user-agent-defined// - - (match usage
throughout document)
---
11.4.10 The input element as a button
element's type attribute in a user-agent-defined (and probably
locale-specific) fashion
S//user-agent defined//user-agent-defined// - - (match usage
throughout document)
---
Re: [whatwg] Global Script proposal.
This is an interesting suggestion as it isolates the stateful parts from the rest of the previous suggestions. I like state. Here's how I see how it fits inside the big picture: Scope Serialized state Live state - -- user agent WS_localStorage, GlobalScript [2] SharedWorker [1] cookie browsing context WS_sessionStorage- [3] window.name document -plain JS objs [4] history entry History.pushStateplain JS objs [4] [1] Global state can be coordinated by a SharedWorker but it would need to be serialized in postMessage on transfer so that's why I've put it in the serialized column. [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. [3] You also mention that the feature could be usable for page-to-page navigation within the same browsing context. It hasn't been suggested yet, but it would be possible to have a variation of GlobalScript that binds to a specific browsing context, analogous to sessionStorage. [4] These plain JavaScript objects indeed live throughout their Document's life, but this lifetime is usually shorter than what the user's perception tells him. Ie, when the user returns to a previous page through the Back button he regards that as the same document, while technically it's usually a new Document, with a freshly created document tree and JavaScript context. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? Best regards Mike Wilson From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov Sent: den 17 augusti 2009 23:38 To: wha...@whatwg.org Subject: [whatwg] Global Script proposal. Dear whatwg, The previous discussion about shared page and persistence has sent us back 'to the drawing board', to think again what is the essence of the feature and what's not important. Talking with web apps developers indicates the most of benefits can be achieved without dangerous background persistence or the difficulty to specify visual aspects of the invisible page. Here is the new proposal. Your feedback is very appreciated. We are thinking about feasibility of doing experimental implementation in WebKit/Chrome. Thanks! - SUMMARY Currently there is no mechanism to directly share DOM, code and data on the same ui thread across several pages of the web application. Multi-page applications and the sites that navigate from page to page would benefit from having access to a shared global script context (naming?) with direct synchronous script access and ability to manipulate DOM. This would compliment Shared Workers (http://www.whatwg.org/specs/web-workers/current-work/) by providing a shared script-based context which does not run on a separate thread and can be used directly from the application's pages. USE CASES Chat application opens separate window for each conversation. Any opened window may be closed and user expectation is that remaining windows continue to work fine. Loading essentially whole chat application and maintaining data structures (roster) in each window takes a lot of resources and cpu. Finance site could open multiple windows to show information about particular stocks. At the same time, each page often includes data-bound UI components reflecting real-time market data, breaking news etc. It is very natural to have a shared context which can be directly accessed by UI on those pages, so only one set of info is maintained. A game may open multiple windows sharing the same model to provide different views at the game objects (as in flight simulator). In an email application, a user may want to open a separate compose window for a new email, often after she started to answer in place but realized she'd like to look up something else in the mailbox for the answer. This could be an instantaneous operation if the whole html tree and the compose editor script were shared. Such multiple-window use cases could be simpler and use much less resources if they had access to a shared Global Script Context so there is no need to re-initialize and maintain the same state in all the pages. Having direct, same-thread DOM/JS access to this context makes it possible to avoid loading and initialization of repetitive code and data, makes separate
Re: [whatwg] Spec comments, section 4.8
On Tue, Aug 18, 2009 at 6:45 AM, Kevin Bensonkevin.m.ben...@gmail.com wrote: Their purpose is described later in 4.8.10.5 Loading the media resource at step 20: Yes, but maybe a different character could be chosen, if this one doesn't consistently display in browsers. Sentence #1 Recommends unobtrusive implementation of UI features (for author's sake). Sentence #2 Permits override of boolean attribute for implementation of UI features. (for UA's sake) But ends with a colon, which together with the following suggests a list of some sort was meant to come after it. Sentence #3 Recommends unobtrusive implementation of UI features (for client's sake). Which duplicates sentence #1, even though that was only two sentences before. So again it looks to me like there was originally something in between that made this look less redundant. As it stands it definitely reads strangely to me, anyway. (I looked in the version history, but it didn't explain much. The paragraph was added as-is in r678 commented out, then uncommented in r697.)
Re: [whatwg] Spec comments, section 4.8
On Tue, Aug 18, 2009 at 10:34 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Aug 18, 2009 at 6:45 AM, Kevin Bensonkevin.m.ben...@gmail.com wrote: Their purpose is described later in 4.8.10.5 Loading the media resource at step 20: Yes, but maybe a different character could be chosen, if this one doesn't consistently display in browsers. Agreed. Maybe the symbol being used for the Resource Fetch Algorithm steps, (further down) where it reads resource fetch algorithm for a media element and a given absolute URL: ↪ 'RIGHTWARDS ARROW WITH HOOK' (U+21AA) would work better (for marking the Steps in synchronous sections) as an intermediary pointer symbol that follows the step number and precedes the step description because there is precious little whitespace between, whereas the resource fetch algorithm subsections have no numbering scheme to deal with _and_ all whitespace to the left of the steps' descriptions. (ie. Any bulleting symbol would suffice and serve the purpose.) Or it could be browser- and font-agnostic enough to even facilitate display in IE :) Something like, maybe common math symbols such as: ≈ 'ALMOST EQUAL TO' (U+2248) or ± 'PLUS-MINUS SIGN' (U+00B1) or whatever. (Just thinking aloud.) Sentence #1 Recommends unobtrusive implementation of UI features (for author's sake). Sentence #2 Permits override of boolean attribute for implementation of UI features. (for UA's sake) But ends with a colon, which together with the following suggests a list of some sort was meant to come after it. Yeah, I missed that colon, but the features _are_ listed after these sentences. It just doesn't stand out as _a list_ . Sentence #3 Recommends unobtrusive implementation of UI features (for client's sake). Which duplicates sentence #1, even though that was only two sentences before. So again it looks to me like there was originally something in between that made this look less redundant. As it stands it definitely reads strangely to me, anyway. (I looked in the version history, but it didn't explain much. The paragraph was added as-is in r678 commented out, then uncommented in r697.) I agree that the intent was probably superseded by the result. I almost get the sense that the pairs of sentences were originally reversed (or the alternating sentences were). Anyways, words and sentences can _always_ be condensed and combined. Clarity remains the objective and redundancy the enemy. -- -- -- -- ô¿ô¬ K e V i N /¯\
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: This is an interesting suggestion as it isolates the stateful parts from the rest of the previous suggestions. I like state. Here's how I see how it fits inside the big picture: Scope Serialized state Live state - -- user agent WS_localStorage, GlobalScript [2] SharedWorker [1] cookie browsing context WS_sessionStorage- [3] window.name document -plain JS objs [4] history entry History.pushStateplain JS objs [4] [1] Global state can be coordinated by a SharedWorker but it would need to be serialized in postMessage on transfer so that's why I've put it in the serialized column. [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. [3] You also mention that the feature could be usable for page-to-page navigation within the same browsing context. It hasn't been suggested yet, but it would be possible to have a variation of GlobalScript that binds to a specific browsing context, analogous to sessionStorage. [4] These plain JavaScript objects indeed live throughout their Document's life, but this lifetime is usually shorter than what the user's perception tells him. Ie, when the user returns to a previous page through the Back button he regards that as the same document, while technically it's usually a new Document, with a freshly created document tree and JavaScript context. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Best regards Mike Wilson From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov Sent: den 17 augusti 2009 23:38 To: wha...@whatwg.org Subject: [whatwg] Global Script proposal. Dear whatwg, The previous discussion about shared page and persistence has sent us back 'to the drawing board', to think again what is the essence of the feature and what's not important. Talking with web apps developers indicates the most of benefits can be achieved without dangerous background persistence or the difficulty to specify visual aspects of the invisible page. Here is the new proposal. Your feedback is very appreciated. We are thinking about feasibility of doing experimental implementation in WebKit/Chrome. Thanks! - SUMMARY Currently there is no mechanism to directly share DOM, code and data on the same ui thread across several pages of the web application. Multi-page applications and the sites that navigate from page to page would benefit from having access to a shared global script context (naming?) with direct synchronous script access and ability to manipulate DOM. This would compliment Shared Workers (http://www.whatwg.org/specs/web-workers/current-work/) by providing a shared script-based context which does not run on a separate thread and can be used directly from the application's pages. USE CASES Chat application opens separate window for each conversation. Any opened window may be closed and user expectation is that remaining windows continue to work fine. Loading essentially whole chat application and maintaining data structures (roster) in each window takes a lot of resources and cpu. Finance site could open multiple windows to show information about particular stocks. At the same time, each page often includes data-bound UI components reflecting real-time market data, breaking news etc. It is very natural to have a shared context which can be directly accessed by UI on those pages, so only one set of info is maintained. A game
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. It can, but with a caveat: in case of user agents that are multi-process, in some cases there will be more then one Global Script instance. For example, lets say there is a process for the tab opened for site S1 and there is another process with a tab for site S2. if S2 has iframe pointing to S1, the page in that iframe will get a separate instance of the Global Script since it can't access the one which is created for the tab showing S1. It is equivalent to running the same app in different browsers... So it's across browser contexts in the same process. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? The Global Script would run on the main thread of the browser - same one where all the JS on visible pages is executing. It can (and should) use Workers to unload work from ui tread but its use cases are all around running synchronously on the same thread as UI pages of the application, so that it's possible to keep event handlers in it or update the shared UI state synchronously (for example, user selects an image in a document - the toolbar buttons with image operations become active). Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? Since there is a direct JS access to the Global Script on the main thread of the browser, that would require something like synchronous JS IPC. While theoretically possible, it is very complicated to retrofit the existing browsers for that; it can have issues with performance of JS (especially JIT types of JS engines) and it also has disadvantages of any sync API that may block on a remote resource (since another process is independent and may have its own reasons to block).
Re: [whatwg] Global Script proposal.
Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Certainly, the ideal case is that they are in the same process. Using proxies is coming back to serialization all over again, although transparent. What I was commenting was the (seemingly widespread) notion that it is impossible to share data between process, which is not true. There is nothing stopping an implementation from using direct calls whenever process sharing is possible, and falling back to proxies in cases when processes need to be different. With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? Also, what about shared memory (I'm assuming everybody knows what this is) - apart from being non-trivial stuff, are there any specific drawbacks that renders it not useful for this case? Best regards Mike
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. - a
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 12:00 AM, Darin Fisherda...@chromium.org wrote: I agree. Moreover, since a shared worker identified by a given name cannot be navigated elsewhere, the name isn't all that synonymous with other usages of names (e.g., window.open). At the very least, it would seem helpful to scope the name to the URL to avoid the name conflict issue. -Darin Technically, that can already be done by using the current the current URL as the name. / Jonas
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:32 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. Btw, I thought I'd just point out that the proposal mentions this case: From the proposal text: All pages connected to the same Global Script should run on the same thread, in the same process. Since this is not always technically possible, it should be legal (and not break the applications) for there to be duplicate global script contexts within a UA. I'm glad this came up, however, since now it's more clear why such language is necessary.
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Certainly, the ideal case is that they are in the same process. Using proxies is coming back to serialization all over again, although transparent. What I was commenting was the (seemingly widespread) notion that it is impossible to share data between process, which is not true. There is nothing stopping an implementation from using direct calls whenever process sharing is possible, and falling back to proxies in cases when processes need to be different. With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) Also, what about shared memory (I'm assuming everybody knows what this is) - apart from being non-trivial stuff, are there any specific drawbacks that renders it not useful for this case? I think it being non-trivial is the only issue. When it becomes necessary for performance reasons, I'm sure people will start looking at this. J
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 1:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 18, 2009 at 12:00 AM, Darin Fisherda...@chromium.org wrote: I agree. Moreover, since a shared worker identified by a given name cannot be navigated elsewhere, the name isn't all that synonymous with other usages of names (e.g., window.open). At the very least, it would seem helpful to scope the name to the URL to avoid the name conflict issue. -Darin Technically, that can already be done by using the current the current URL as the name. I don't quite understand. Are you suggesting that you can work around this by passing the same parameter twice when creating a shared worker? If so, that seems ugly...and a sign that it should be changed.
[whatwg] Storage mutex
I was looking through the WebStorage and HTML 5 specs regarding the storage mutex. I have a few comments/questions. First of all, I was wondering why all user prompts are specified as must release the storage mutex ( http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this really say must instead of may? IIRC (I couldn't find the original thread, unfortunately) this was added because of deadlock concerns. It seems like there might be some UA implementation specific ways this could deadlock and there is the question of whether we'd want an alert() while holding the lock to block other execution requiring the lock, but I don't see why the language should be must. For Chromium, I don't think we'll need to release the lock for any of these, unless there's some deadlock scenario I'm missing here. It's also worth noting that Chromium is probably going to need to drop the storage mutex for most if not all plugin related calls due to deadlock conditions. If there were some place to mention this as a may type thing, it'd be good, but I realize it's probably out of scope for HTML 5. Given that different UAs are probably going to have other scenarios where they have to drop the lock (some of them may even be purely implementational issues), should we add some way for us to notify scripts the lock was dropped? A normal event isn't going to be of much use, since it'll fire after the scripts execution ends (so the lock would have been dropped by then anyway). A boolean doesn't seem super useful, but it's better than nothing and could help debugging. Maybe fire an exception? Are there other options? Lastly, is navigator.getStorageUpdates() the right name for the function that drops the lock? Why was it changed from navigator.releaseLock()? I assume we're trying to avoid the word lock, but the reason why you'd need to call a function to get updates is not clear without understanding the concept of a lock...so what's the point of making this so cryptic? Thanks, Jeremy
[whatwg] Proposed changes to the History API
I'm in the process of implementing the HTML5 History API (History.pushState(), History.clearState(), and the PopState event) in Firefox. I'd like to discuss whether the API might benefit from some changes. To my knowledge, no other browser implements this API, so I'm assuming we have freedom to make large alterations to it. My basic proposal is that History.pushState() be split into a function for creating new history entries and functions or a property for getting/setting an object associated with that entry. In its current form, the History API allows us to identify session history entries by way of an arbitrary object, which we pass as the first argument to pushState() and which we receive as part of the PopState event when that history entry is activated. If the page gets a null popstate, it's supposed to use the URL to decide what state to display. Notably unsupported by this API is support for pages altering their saved state. For instance, a page might want to save a text box's edit history to implement a fancy undo. It could store the edit history in a cookie or in the session storage, but then if we loaded the page twice in the same tab, those two instances would step on each other when we went back and forth between them. The page could just store its state in variables in the document, but then it would loose that state when the browser crashed or was closed, or when the browser decided to kick the document out of the history. I think this page would be better served by a History.setStateObject() function, which does exactly what the page wants in a simple fashion. We'd still keep the history-entry-creating functionality of History.pushState() in a new History function (I'll call it createNewEntry(), but it probably needs a better name), which takes a title and URL, as pushState() does now. The API might be more intuitive if we had a History.stateObject propery, but I'm concerned that then we'd be promising the page that we'll keep around literally any objects it wants, including DOM objects. In fact, I'd be happy restricting the state object to being a string. If a page wants to store an object, it can convert it to JSON, or it can store a GUID as its state string and index into the session storage. Pages could retrieve the state object just as they do now, in a PopState event, although we'd probably want to change the name of the event. We'd probably want to fire PopState on all loads and history navigations, since any document might have a state to pop, and even those documents which didn't call setStateObject() might store state in their URI which they need to restore when their history entry is activated. Last, I'm not sure that we need the History.clearState() function. It's confusing (why do we end up at the last entry for the current document instead of staying at the current entry?) and I haven't been able to come up with a compelling use case. I think the main benefit of these changes is added simplicity. There's a right and wrong way to use pushState, and setState/createNewEntry doesn't require such rules. But additionally, these changes allow pages flexibility to do things we haven't yet thought of. I don't know what those things might be, but I suspect they may be pretty cool. :) -Justin
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 3:08 PM, Jeremy Orlowjor...@chromium.org wrote: On Tue, Aug 18, 2009 at 1:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 18, 2009 at 12:00 AM, Darin Fisherda...@chromium.org wrote: I agree. Moreover, since a shared worker identified by a given name cannot be navigated elsewhere, the name isn't all that synonymous with other usages of names (e.g., window.open). At the very least, it would seem helpful to scope the name to the URL to avoid the name conflict issue. -Darin Technically, that can already be done by using the current the current URL as the name. I don't quite understand. Are you suggesting that you can work around this by passing the same parameter twice when creating a shared worker? If so, that seems ugly...and a sign that it should be changed. No, what I mean is that if you want to create a worker shared with other instances of the same page, without having to worry about collisions from other pages on your site, you can do: worker = new SharedWorker(/scripts/workerJSFile.js, document.location); This way you can be sure that no other page on your site happen to use the same name. / Jonas
Re: [whatwg] SharedWorkers and the name parameter
An alternative would be to make the name parameter optional, where omitting the name would create an unnamed worker that is identified/shared only by its url. So pages would only specify the name in cases where they actually want to have multiple instances of a shared worker. -atw On Tue, Aug 18, 2009 at 7:01 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 18, 2009 at 3:08 PM, Jeremy Orlowjor...@chromium.org wrote: On Tue, Aug 18, 2009 at 1:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 18, 2009 at 12:00 AM, Darin Fisherda...@chromium.org wrote: I agree. Moreover, since a shared worker identified by a given name cannot be navigated elsewhere, the name isn't all that synonymous with other usages of names (e.g., window.open). At the very least, it would seem helpful to scope the name to the URL to avoid the name conflict issue. -Darin Technically, that can already be done by using the current the current URL as the name. I don't quite understand. Are you suggesting that you can work around this by passing the same parameter twice when creating a shared worker? If so, that seems ugly...and a sign that it should be changed. No, what I mean is that if you want to create a worker shared with other instances of the same page, without having to worry about collisions from other pages on your site, you can do: worker = new SharedWorker(/scripts/workerJSFile.js, document.location); This way you can be sure that no other page on your site happen to use the same name. / Jonas
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 7:53 PM, Drew Wilsonatwil...@google.com wrote: An alternative would be to make the name parameter optional, where omitting the name would create an unnamed worker that is identified/shared only by its url. So pages would only specify the name in cases where they actually want to have multiple instances of a shared worker. -atw This seems like a very good idea. Makes a lot of sense that if two shared workers have the same uri, you are probably going to interact with it the same way everywhere. Only in less common cases do you need to instantiate different workers for the same url, in which case you can use the name parameter. / Jonas
