<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">Dion: The problem here is that isn't backwards compatible and thus no-one will really be able to use it. </blockquote><br><div>I thought the original idea was backwards compatible. Maybe not the URN Schemes. If the original idea is not, could you point out the issues?</div><div><br></div><div><br></div><div><blockquote type="cite">Dion: You then also get into the "how do I get my library into the browser?"</blockquote><div><font class="Apple-style-span" color="#144FAE"><br></font></div><div><font class="Apple-style-span" color="#144FAE"><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">Enough widespread usage of a library is a clear indicator for adoption into a browser bundle. Dynamically growing repositories could optimize per computer for the particular user's browsing habits (assuming developers would mark their scripts with the identifiers).</span></font></div><div><br></div><div><font class="Apple-style-span" color="#144FAE"><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">You can have the same problem with what libraries will Google include in its CDN. Although it may be easier for Google to host just about any library if it already has a CDN setup. </span></font></div></div><div><br></div><br><blockquote type="cite"><div>Dion: After mulling this over with the Google CDN work, I think that using HTTP and the browser mechanisms that we have now gives us a lot without any of these issues.<br></div></blockquote><div><br></div><div>I was afraid of this. This is a completely valid point. I guess it sounds like too much work for too little gain?</div><div><br></div><div>- Joe</div></div></body></html>