I think a "remote" type of attribute would be interesting to bring up with the standards bodies. Discuss having that introduced for link and script elements. With the flow I brought up in my second email in the thread. That coupled with the integrity hash (or not, hash just for extra security) would be a really clean system for pulling in external resources or falling back to local if not found. This way we could also avoid things like the jQuery check [1] in the H5BP.
So I guess I'll be sending an email to the WhatWG public email list in a day or two for comments (or another ML if I find a more appropriate one looking around.) Thanks for the discussion Alex! Much appreciated. -Garbee [1] https://github.com/h5bp/html5-boilerplate/blob/master/index.html#L25 On Fri, May 2, 2014 at 6:51 PM, Alex Komoroske <[email protected]> wrote: > > > > On Fri, May 2, 2014 at 3:50 PM, Jonathan Garbee <[email protected] > > wrote: > >> Yea, the whole "canonical" CDN point is pretty moot imo. Because people >> will disagree with how things are done or just find a reason to make their >> own. Further even if you have a CDN, the splitting between versions of an >> item causes fracturing among the cache base. However, something that was >> talked about was like a community code review kind of system. It would be >> cool too if there were a community repository like CDNJS (or possibly even >> talk with these guys to expand CDNJS to allow web components) where anyone >> can submit their component in a structured way for sharing. Of course, this >> takes money and someone needs to put that up for it to operate in the first >> place which means proving its worth. >> >> We can never fully eliminate duplicate cached items. However, something >> that could be aimed for is a "most canonical" CDN (like Google's AJAX CDN >> seems to be for jQuery) which would try and have as many caches as >> possible. This way developers can try to give the best possible performance >> to clients and use less disk space. Because if 300 sites use a web >> component that a user visits, having it cached from one CDN (even if 4 >> versions) is better than 300 different cached copies from each location >> taking up space. >> >> Your hash of the resource point is interesting. But I'm worried about the >> "I don't care where it came from" part. We know that it is possible to >> craft things to cause a hash collision in some scenarios, so who is to say >> someone doesn't make malicious stuff on their site to hand out just to >> conflict with other peoples stuff? So maybe we need to get a smarter brain >> on hashes to talk about that kind of attack with. >> > > Yeah, that part seems to be the dealbreaker. > >> >> >> On Fri, May 2, 2014 at 11:49 AM, Alex Komoroske <[email protected]>wrote: >> >>> [+ slightlyoff, who knows much more about these kinds of things than I >>> do] >>> >>> >>> On Fri, May 2, 2014 at 8:01 AM, Jonathan Garbee < >>> [email protected]> wrote: >>> >>>> I just had an interesting idea from you mentioning "new specs"... >>>> >>>> What if there was a new attribute introduced. Something like "remote". >>>> Following something like the subresource integrity specificiation [1] >>>> draft. So you could declare the remote attribute on an import. So *if* the >>>> remote source is already cached then use that. If it isn't, try to pull it >>>> from there. If a link can't be established, then fallback to using your >>>> hosted version. Adds some extra time to the request if the CDN can't be >>>> hit, but would allow shared resources with a fallback in a simple way. >>>> Possibly even could be coupled with an integrity check to verify the bits >>>> are right. >>>> >>> >>> This scheme is interesting, but it doesn't seem to address the primary >>> challenge: getting people to all point to the same "canonical" CDN. It >>> would be totally rad if people could say "here's the hash of the resource >>> I'm looking for. I've got it hosted here, but if you already have a cached >>> resource with this hash, no matter where it came from, just use that." >>> Then, everyone doesn't have to agree on the same CDN to point to. >>> >>> I don't pretend to have the requisite expertise here, by the way, so >>> take all of my comments with a grain of salt. :-) >>> >>> >>>> >>>> [1] http://w3c.github.io/webappsec/specs/subresourceintegrity/ >>>> >>>> >>>> On Fri, May 2, 2014 at 10:21 AM, Alex Komoroske >>>> <[email protected]>wrote: >>>> >>>>> Hi, Garbee! Great to see you! :-) >>>>> >>>>> >>>>> On Fri, May 2, 2014 at 6:40 AM, Jonathan Garbee < >>>>> [email protected]> wrote: >>>>> >>>>>> When Alex was answering my moderator question in the All About >>>>>> Polymer gathering at the SFHTML5 event he mentioned that the components >>>>>> are/can be cached locally. This made me think two things. First, this is >>>>>> fantastic since instead of using a backend to generate the same structure >>>>>> of code over-and-over again to send across the internet, you can just >>>>>> generate a few tags and push down far fewer bits overall on your site. >>>>>> Which is just fantastic for overall performance, especially on mobile >>>>>> networks. >>>>>> >>>>>> However, that led me to another thought. What about sites sharing the >>>>>> same components? Developers are being urged to make their components >>>>>> generic so anyone can easily pick them up and integrate them. Would it be >>>>>> beneficial to provide a CDN for components to be hosted from? That way >>>>>> sites that are using the same components but aren't modifying them could >>>>>> then save some resources by using the same CDN hosted copy. This not only >>>>>> saves more data going across networks but also decreases the overall >>>>>> cache >>>>>> size on clients. >>>>>> >>>>> >>>>> We've explicitly thought about something like this. We've also >>>>> slightly crazier solutions that would require new specs but allow more >>>>> clever caching strategies. All of the solutions get complex relatively >>>>> quickly, for different reasons. >>>>> >>>>> At this point our goal is that tools like Vulcanizer help us, at the >>>>> very, very least, be as good as the current best practice status quo. >>>>> However, I think that as the web components ecosystem takes off this will >>>>> be a very interesting topic to dive into in more depth. >>>>> >>>>> >>>>>> >>>>>> Does anyone have any thoughts on the benefits and drawbacks of a Web >>>>>> Components CDN? Or is there a discussion of this before around that I >>>>>> missed in searching? >>>>>> >>>>>> Thanks, >>>>>> -Garbee >>>>>> >>>>>> 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/3cb1ca5a-32e7-40a3-9ec0-8615836b772d%40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/3cb1ca5a-32e7-40a3-9ec0-8615836b772d%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/CANQy2y2zWnq80toVyuWNkV84VNTvrKE2WhWySjWmHdmHJva0WQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
