[whatwg] SharedWorkers and the name parameter

[Michael Nordman]

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.shaver at gmail.com> wrote:

> On Sat, Aug 15, 2009 at 8:29 PM, Jim Jewett<jimjjewett at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090817/b5c4551c/attachment.htm>