[whatwg] SharedWorkers and the name parameter

Michael Nordman michaeln at google.com
Sun Aug 16 12:51:41 PDT 2009


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?

// 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 <atwilson at 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 <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.
>>
>> -jJ
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090816/9449f8b3/attachment.htm>


More information about the whatwg mailing list