On Fri Jul 11 2014 at 11:01:05 AM, Michael Bleigh <[email protected]> wrote:
> 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. > Yeah, you're right here - the hashing approach really only tackles *identical* resources, and your suggested approach below nicely circumvents that :) > 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"> > I like this! Best of all it's *simple* and *obvious* to the 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. > > I tend to agree, after watching various communities try to adhere to semantic versioning to varying degrees of success, it seems too heavy-handed. Why not just treat them as strings? You could even cheat a little: <link rel="import" href="https://api.foo.com/bar.html <https://api.github.com/wc/repo.html>" imports="bar-awesome bar-awesome@0 [email protected] [email protected]"> This example is probably overkill, but is certainly flexible. > > 1. 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){ } > Starts to sound pretty similar, mechanically, to ES6 modules > 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]> >> 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]. >>> >> >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/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 >>> <https://groups.google.com/d/msgid/polymer-dev/4b09301e-053a-4402-8d2d-1afb1e5490dd%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/CAKc-BFiSTPCi3K9r8jFRVYYCLTUGoVdgPKULOpOoMsRk7_Hwpw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
