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|sort: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/ > 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/CAKc-BFiFRvuRgLOKWrt9Ae79dzBr5aW1zHjzK%2BcrvUzGsPDNGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
