- From: Michael Nordman <michaeln@google.com>
- Date: Sun, 16 Aug 2009 12:51:41 -0700
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>
Received on Sunday, 16 August 2009 12:51:41 UTC