Thanks for the links! That's super-helpful. Completely agree that import-time is the right time to tackle this. Also agree that it's possible that a new spec would need to be added to really make this work.
Unless I'm misunderstanding, it seems like the security concerns wouldn't be that big of a deal. You should never, ever be importing content from a source you don't already trust, so some form of resource hashing seems like it would only be an efficiency/deduplication issue, not a security issue. I can imagine something like a "unique" or "once" attribute on <link> that would basically say "don't load this resource if it's already been loaded." However this would require fetching and hashing the resource (or having an agreed-upon header to respond with in HEAD to verify the hash), which means you're still sending the data over the wire. One way to manage this in a way that leaves most of the solution up to userland (which is imo a good idea in most cases) would be to have an attribute on the link tag called e.g. imports that would be a space-delimited token attribute. The idea here would be that if the resources specified by imports are already loaded (or already being loaded from an uncomplete import) they are simply skipped. Of course a <link> tag without this attribute would load regardless. To illustrate what I mean, imagine something like this: <link rel="import" href="https://api.github.com/wc/repo.html"; imports="core-ajax github-repo github-user"> You would want to have some kind of canonical API to be able to manipulate imports via JS as well, something like document.imports. OK, so this would solve some of our problems but leave others: 1. What about conflicting versions of an import? We could do versioning e.g. [email protected] but we can't really expect to put semantic versioning into an HTML spec. 2. Depending on the import, that "imports" list could become very long indeed. 2. is a mostly aesthetic concern and I suppose the length of your imports list would be determined by how much you care about dependency deduplication. 1. is a much trickier issue, and to solve it I would propose that you be able to actually reach in and define the import resolver yourself. For example, document.imports.resolver = function(import){ } If you did that, you'd be able to slot in something for whatever system you like that maybe *would* understand semantic versioning and throw errors when versions are too mismatched but allow minor version incompatibilities, etc. You could even theoretically feed it configuration a la bower.json and let it run from there. Eric's HTML5 Rocks article is titled "HTML Imports: #include for the web". I think that's a fantastic ideal but one that isn't quite being lived up to yet. Until we're able to properly resolve dependency conflicts and multiple imports, we're not going to be able to simply import and forget it. Obviously the Polymer team is running head-on into this issue by the universal use of Bower, a third-party package manager. I know there has to be a way to do this natively in a way that still allows for proper userland expansion. Anyways, thanks for taking the time to listen to my rambling, would love to discuss further. On Friday, July 11, 2014 10:35:24 AM UTC-7, Ian MacLeod wrote: > > Here's some previous threads that might help spur some discussion: > > - Canonical CDNs? > > <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/cdn/polymer-dev/Dz6yIqMO2cc/1w2957gLXs4J> > > (not really) > - Centralized components host? > > <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/import%7Csort:date/polymer-dev/Dz6yIqMO2cc/BdPd1KJhbUQJ> > - AMD/requirejs + imports? > > <https://groups.google.com/forum/?fromgroups=#!searchin/polymer-dev/import%7Csort:date/polymer-dev/bdSyt-QXFE8/ohRr1ucTRYMJ> > > - ... and some others that I'm totally failing to find :( > - Also, there's core-shared-lib > <https://github.com/Polymer/core-shared-lib> which sorta tackles this > > > It feels like it's best to tackle that at import time (as opposed to > registration time) - purely for reducing bytes over the wire. Though, it's > not clear how to do that w/o adding a ton of complexity to imports. > > It'd be interesting to have some sort of scheme where you can identify > assets via some means *other* than a URL. Probably some sort of hash, > cert, or signature. Doing it in a secure way would be challenging, though > > On Fri Jul 11 2014 at 10:19:43 AM, Michael Bleigh <[email protected] > <javascript:>> wrote: > >> Something that I've been thinking a lot about lately is the idea of >> companies offering importable elements instead of their existing JavaScript >> APIs. So Mixpanel, or Google Analytics, or even GitHub would, instead of >> saying "load this JS" just say: >> >> <link rel="import" href="https://api.some-company.com/api.html";> >> >> Which I think is a fantastic and exciting premise! What isn't as clear or >> exciting is how to manage the potentially conflicting dependencies. Let's >> say that the imported API element uses core-ajax but so does my >> application. How is that conflict resolved? >> >> Of course Bower solves this by simply only having one of a given >> dependency, but we're talking about the Web Platform here and Bower, cool >> as it is, isn't really core Web Platform tech. Not to mention that there >> are big potential wins to being able to import an always-up-to-date API >> directly from the source. >> >> Right now it *seems* as though first-to-register wins. I see errors in my >> console if an element tries to be registered twice. But I'm not certain >> whether the Polymer behaviors are likewise ignored, are re-applied to the >> existing definition, or what. >> >> Basically I just think this is something that merits some thought and >> discussion, and I'd love to hear what you all think. >> >> Follow Polymer on Google+: plus.google.com/107187849809354688692 >> --- >> You received this message because you are subscribed to the Google Groups >> "Polymer" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/polymer-dev/93ab4fd9-adba-49a3-9368-03e6f5166509%40googlegroups.com >> <https://groups.google.com/d/msgid/polymer-dev/93ab4fd9-adba-49a3-9368-03e6f5166509%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/4b09301e-053a-4402-8d2d-1afb1e5490dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
