[+ 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/CAPwaZpVrdEFdTOMC8aq7aR0z7eUp81shAi%2BbJK7uRjmgisu5LA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
