Hi Kam, On Wed, May 26, 2010 at 7:34 PM, Kam Kasravi <[email protected]> wrote: > This problem has many similarities to the XML / WSDL world. > The use of namespaces and versioning has been leveraged there to > disambiguate names ...
That's a very interesting idea, thank you. I whiteboarded this a bit and here's what I came up with. I will refer to management of "modules" here in order not to introduce extra machinery. However, we would wish to use this scheme to manage *collections* of modules that are distributed and developed together. So, for example, instead of using this scheme to manage the Accordion module, we would use it to manage the entirety of YUI, and select individual pieces from that. I will try to extend from individual modules to collections at the end of the post. Assume each module has a canonical URL (cURL). This serves as a global *name* for the module, not a location. It incorporates DNS addresses and thus allows for decentralized name assignment. As you point out, it follows the precedent of W3C usage. For example, some cURLs might be: http://yahoo.com/frameworks/YUI http://jquery.com/jquery The guidance about whether your library should be assigned a new cURL or given an existing one is that you have to answer the question: "Does it make sense for multiple independent instances of my library to be running within the same loader?" If the answer is "Yes", then you should use a separate cURL. If not, then you shouldn't. Practically speaking, distinct versions of a library should *not* have distinct cURLs, but libraries that do completely different things should. To instantiate a loader, you supply a catalog. The catalog maps cURLs to actual code resources. It may do so in any of a number of ways: by consulting some third party; by keeping a literal table; by implementing some general code that does a Google search; whatever. The important thing is the contract of a catalog: For each distinct cURL, there exists zero or one code resources: http://yahoo.com/frameworks/YUI => retrieve "http://http://developer.yahoo.com/yui/3/download/yui-min.js"; http://jquery.com/jquery => retrieve "http://code.jquery.com/jquery-1.4.2.min.js"; [anything else] => [undefined] If a catalog does not contain (in the general sense, meaning "cannot locate") a code resource for a cURL, it fails fast; there is no facility for an individual module to render its own "opinion" about what a cURL maps to. If the module wishes to implement a new or extended (cURL -> code) mapping, it does so by instantiating a new loader. To review: the usefulness of cURLs is that they provide a reasonable, distributed, Webby way to manage the *key* space of catalogs. They do not themselves implement the catalogs. One can imagine sites out there that *host* catalogs, for everyone's convenience, and one can connect one's loader to one of these; build code that uses these catalogs but overrides a couple of entries; whatever. The naming "substitution" attack scenario is safe. If I go rogue and decide to camp on the name "http://jquery.com/jquery"; with my own crazy library, nothing prevents me -- *but* I have to go convince the authors of all the catalogs in the world to map: http://jquery.com/jquery => retrieve "http://ihabsmalware.com/badjquery.js"; which is an unlikely scenario. As for collections of modules, we can map cURLs to some notion of "packages", or we can design "entry point" JS files that pull in all the contents of their respective modules, or whatever. I'm sure we can come up with a design were we to accept this approach. * * * * * The following are the remaining questions in my mind: 1. How much should we standardize? To my mind, the use of cURLs simply provides a plausibility argument for having "globally recognizable" keys in catalogs, but should not be mandated. 2. How does this support the casual development model where a developer writes up some module but does not attempt (or does not have the resources) to choose a cURL for it? How can this module be used in a simple manner? Clearly, if this module is to be used in a loader, *and* if it wishes to be treated as a singleton, the loader should assign it a name unique within that loader. How is that done? By using the exact *location* URL for that library as the library's cURL? That means we are doing "url equality" -- an evil. But at least we are doing it in a controlled manner.... 3. What is the syntax for importing? I imagine something like a library using jQuery saying: from "http://jquery.com/jquery"; import { ... }; Ihab -- Ihab A.B. Awad, Palo Alto, CA _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
