Re: [whatwg] SharedWorkers and the name parameter
On Tue, 25 Aug 2009, Jim Jewett wrote: On Tue, Aug 25, 2009 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name The idea here is that if you have an app that does database manipulation, you might want to ensure there is only ever one shared worker doing the manipulation, so you might decide on a shared worker name that is in charge of that, and then you can be sure that you don't accidentally start two workers with that name using different copies of a script So the name is really intended as a (lightweight) URN, but it can default to the URL? The name is an opaque string. It can be whatever you want. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SharedWorkers and the name parameter
On Tue, 25 Aug 2009, Drew Wilson wrote: On Tue, Aug 25, 2009 at 4:24 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 18 Aug 2009, Drew Wilson 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. Done. Thanks for adding this, Ian. However, the resulting spec language is subtly different from what I was proposing. Section 4.8.3 of the spec now reads: 4. Let name be the value of the second argument, or the value of scriptURL, if the second argument was omitted. My reading of this is if I do the following: var worker1 = new SharedWorker(http://www.example.com/worker;, http://www.example.com/worker2;); Then try to do this: var worker2 = new SharedWorker(http://www.example.com/worker2;); The second invocation of the constructor would throw a URL_MISMATCH_ERR, since the name http://www.example.com/worker2; is already associated with the script at http://www.example.com/worker;. Yeah, good point. Ok, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] SharedWorkers and the name parameter
Drew Wilson 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. Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. Additionally, a typo in one page (i.e. invoking SharedWorker(mypagescript?, name) instead of SharedWorker(mypagescript, name) will keep all subsequent pages in that domain from loading a worker under that name so long as the original page resides in the page cache. I'd* like to propose changing the spec so that the name is not associated with the origin, but instead with the URL itself. So if a page wanted to have multiple instances of a SharedWorker using the same URL, it could do this: new SharedWorker(url.js, name); new SharedWorker(url.js, name2); Nothing would prevent a page from also doing this, however: new SharedWorker(other_url.js, name); The idea here is that if you have an app that does database manipulation, you might want to ensure there is only ever one shared worker doing the manipulation, so you might decide on a shared worker name that is in charge of that, and then you can be sure that you don't accidentally start two workers with that name using different copies of a script (e.g. because you have two installations of WordPress and they both use relative URLs to the same script in their respective locations). On Sat, 15 Aug 2009, Jim Jewett 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. That seems like abuse of the fragment identifier syntax. On Mon, 17 Aug 2009, Michael Nordman wrote: What purpose the the 'name' serve? It's intended to prevent two scripts from being opened for the same purpose by mistake. Can the 'name' be used independently of the 'url' in any way? No. * Is 'name' visible to the web developer any place besides those two? No. On Tue, 18 Aug 2009, Drew Wilson 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. Done. On Sun, 16 Aug 2009, Mike Wilson wrote: Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. I agree with you that this is a problem, and the same problem exists in WebStorage (storage areas are set up per origin). F ex, the sites http://www.google.com/calendar and http://www.google.com/reader, and every other site based off www.google.com will compete for the same keys in one big shared storage area. It seems lately everything is being based on having unique host names, and path is not being considered anymore, which I think it should. The reason it's not is that it would mislead people into thinking that you could do things safely based just on the path, which you can't. A script could trivially poke into another path's databases or cookies, e.g. On Mon, 17 Aug 2009, Laurence Ph. wrote: | If worker global scope's location attribute represents an absolute | URL that is not *exactly equal* to the resulting absolute URL, then | throw a URL_MISMATCH_ERR exception and abort all these steps. Seems the #name part will break this line and throw a URL_MISMATCH_ERR with the duplicated #name2 one. Shall we ignore minor difference
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 25, 2009 at 7:24 PM, Ian Hicksoni...@hixie.ch wrote: Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name The idea here is that if you have an app that does database manipulation, you might want to ensure there is only ever one shared worker doing the manipulation, so you might decide on a shared worker name that is in charge of that, and then you can be sure that you don't accidentally start two workers with that name using different copies of a script So the name is really intended as a (lightweight) URN, but it can default to the URL? -jJ
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 18, 2009 at 8:26 PM, Jonas Sicking jo...@sicking.cc wrote: 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. This sounds reasonable to me. / Jonas
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] 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] 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.
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
Re: [whatwg] SharedWorkers and the name parameter
On Sun, Aug 16, 2009 at 10:51 PM, Michael Nordmanmicha...@google.com wrote: Tim Berners-Lee seems to think this could be a valid use of URI references. http://www.w3.org/DesignIssues/Fragment.html The significance of the fragment identifier is a function of the MIME type of the object Are there any existing semantics defined for fragments on text/java-script objects? do you mean things like text/javascript;version=1.1 ? http://www.google.com/search?hl=enq=%22text%2Fjavascript%3Bversion%22 or text/javascript;e4x=1 ? http://osdir.com/ml/mozilla.devel.jseng/2005-01/msg00061.html
Re: [whatwg] SharedWorkers and the name parameter
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] SharedWorkers and the name parameter
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.com wrote: 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] SharedWorkers and the name parameter
That suggestion has also been floating around in some internal discussions. I'd have to objections to this approach either, although I'm not familiar enough with URL semantics to know if this is a valid use of URL fragments. -atw On Sat, Aug 15, 2009 at 5:29 PM, Jim Jewett jimjjew...@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. -jJ
Re: [whatwg] SharedWorkers and the name parameter
Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. I agree with you that this is a problem, and the same problem exists in WebStorage (storage areas are set up per origin). F ex, the sites http://www.google.com/calendar and http://www.google.com/reader, and every other site based off www.google.com will compete for the same keys in one big shared storage area. It seems lately everything is being based on having unique host names, and path is not being considered anymore, which I think it should. An alternative model would be to follow what cookies do with cookie.path, to allow the application itself decide on what URL should be used as the namespace root. Allowed values would be in the range from the bare host name (~origin) up to the file URL (per your suggestion). (Then if even Document.domain could be enhanced with something to allow subsetting on path it'd be great. But that has probably been discussed to death a long time ago ;-) Best regards Mike Wilson
Re: [whatwg] SharedWorkers and the name parameter
Tim Berners-Lee seems to think this could be a valid use of URI references. http://www.w3.org/DesignIssues/Fragment.htmlThe significance of the fragment identifier is a function of the MIME type of the object Are there any existing semantics defined for fragments on text/java-script objects? // the semantics we're discussing, the naming of a instance loaded script #name=foo // hand wavings at other semantics that could make sense, references to particular items defined in the script #function/global-function-name #var/global-var-name I'd have to objections to thisDid you mean to say i'd have no objectsion to this? On Sun, Aug 16, 2009 at 8:27 AM, Drew Wilson atwil...@google.com wrote: That suggestion has also been floating around in some internal discussions. I'd have to objections to this approach either, although I'm not familiar enough with URL semantics to know if this is a valid use of URL fragments. -atw On Sat, Aug 15, 2009 at 5:29 PM, Jim Jewett jimjjew...@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. -jJ
Re: [whatwg] SharedWorkers and the name parameter
On Sun, Aug 16, 2009 at 12:51 PM, Michael Nordman micha...@google.comwrote: I'd have to objections to this Did you mean to say i'd have no objectsion to this? Yes, I have *no* objections to either approach. Apparently the coffee hadn't quite hit my fingers yet. -atw
[whatwg] SharedWorkers and the name parameter
... Additionally, a typo in one page (i.e. invoking SharedWorker(mypagescript?, name) instead of SharedWorker(mypagescript, name) will keep all subsequent pages in that domain from loading a worker under that name so long as the original page resides in the page cache. In this case, if typo one is invoked after a correct one, an URL_MISMATCH_ERR will be thrown in SharedWorker constructor algorithm step 5.4.2. In the other hand, a 404 will terminate the algorithm and no SharedWorker is created and nothing will be add to global namespace. I think this example won't be a serious problem anyway, though I'm not sure will this cause other problem or not. Use new SharedWorker(url.js#name); and if you want a duplicate, call it new SharedWorker(url.js#name2); This remind me of something: From sec4.8.3, SharedWorker constructor algorithm step 5.4.2: If worker global scope's location attribute represents an absolute URL that is not *exactly equal* to the resulting absolute URL, then throw a URL_MISMATCH_ERR exception and abort all these steps. Seems the #name part will break this line and throw a URL_MISMATCH_ERR with the duplicated #name2 one. Shall we ignore minor difference between urls? e.g # fragments?
[whatwg] SharedWorkers and the name parameter
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. -jJ
[whatwg] SharedWorkers and the name parameter
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. Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. Additionally, a typo in one page (i.e. invoking SharedWorker(mypagescript?, name) instead of SharedWorker(mypagescript, name) will keep all subsequent pages in that domain from loading a worker under that name so long as the original page resides in the page cache. I'd* like to propose changing the spec so that the name is not associated with the origin, but instead with the URL itself. So if a page wanted to have multiple instances of a SharedWorker using the same URL, it could do this: new SharedWorker(url.js, name); new SharedWorker(url.js, name2); Nothing would prevent a page from also doing this, however: new SharedWorker(other_url.js, name); So step 4 in section 4.8.3 would change from this: If there exists a SharedWorkerGlobalScope #sharedworkerglobalscope object whose closing #dom-workerglobalscope-closing flag is false, whose name attribute is exactly equal to the name argument, and whose location#dom-workerglobalscope-location attribute represents an absolute URL that has the same origin as the resulting absolute URL, then run these substeps: to this: If there exists a SharedWorkerGlobalScope #sharedworkerglobalscope object whose closing #dom-workerglobalscope-closing flag is false, whose name attribute is exactly equal to the name argument, and whose location#dom-workerglobalscope-location attribute represents an absolute URL that exactly matches the resulting absolute URL, then run these substeps: The downside of this change is pages might inadvertently create a second instance of a SharedWorker if they inadvertently use the wrong URL. It seems like this is an acceptable tradeoff given the problems described above. What do people think of this? -atw * Thanks to Darin Adler for suggesting this solution
