Take a look
http://www.jsloader.com/demos/

… The browser will view the URL with the specified querystring as a seperate entity than the URL without the querystring.

@Nick: I agree, the server should be stable. The current host has uptime of 99.9%. Really the only thing that will throw it off will be the scalability of the script code that manages the traffic and adds features like querystring-requested expire dates (etc). However, again, the objective is to cache the data with static URIs, not pump heavy traffic continuously. If it’s server stability you want, help me couple your donation with my own donation.

The (old) url I’ve got is: http://jquery.com/src/jquery-latest.js (which redirects – so the new URL may be better).

It’s worked consistently for me for the last year and is great for bookmarklets or just pulling it quickly.

You don’t have to change the URLs to use Amazon S3, at least if you plan ahead.

“Over browsing five different jQuery-driven web sites using the same version of jQuery, there may be five different copies of the script being seperately downloaded.”

Uh, as the cachefile server is configured that’ll happen too using cachefile — and as someone else pointed out, the files are not compressed.

The cachefile server isn’t just missing essential cache headers; it’s actually explicitly telling the browser NOT to cache. Very Clever (not).

– ask

Check the licenses, which are included in the browsable directories. They should all be redistributable. I’ll triple-check myself and pull anything I put up if I realized I goofed up on any particular non-redistributable library.

The issue is that a) I’m certainly not going to be changing any URIs, the primary objective is to keep the URIs static, not just to host the content reliably. And b) if I do go with a CDN or Amazon S3 or something, it will involve a 302 redirect. I’m trying my hardest to avoid 302′s, as that can be almost as expensive as a bad web host to begin with.

I am definitely not interested in going long-term with HostGator.com. This is just an incubation period while static URIs are defined and these logistics are being initially discussed with you, the Internet community.

Just add .nyud.net to your domain name, and you’re done, also you can mirror any file, including your logo, css..etc

Atm it seem to have a network of 260 servers (!) world-wide, not sure about the “speed” and of guaranties what the file will be sure delivered..

I’ll better go for Amazon S3.. But a “foreign” url showing all the time in the status when you browse another page is not very handsome..

Also, the Dojo AOL CDN is more than just a link to the Dojo source, it’s a CDN cross domain build. Are the ones you serve the same, and have you done the same thing for the other toolkits?

the second thing the trust issue could be sovled with server mirroring or more servers offering the same thing.. and yo would only have to upadte you server list once in a while (like emule works)

.. hm. While the site is “donationware” in the sense that there’s a donation link, I do want to emphasize that this was in fact stated tongue-in-cheek and I’m not doing this to try to clean out people’s wallets but to try to help meet a serious need that the web has. Please don’t be offended by the above silliness.

Finally, “they could turn it off at any time”, hm, so I could. But I won’t. I’ve already committed that if I shut the site down, I’ll give at least a month’s notice if anytime very soon, at least a year if it’s been online for the next couple months. In either case, I will add to the forums a way to subscribe to a mailing list for such notifications.

@jordan, I’ll take a look, thanks for the link!

@Dov, *sob* if only I’d seen your site before I started this project, I’d send money your way instead!! I’m sorry. However, I’m also going to go beyond JavaScript and will be keeping an eye out for commonly used DTDs, schamas, microformat css’s, and more. I’ve already included syndication graphics.

@Howie, you make important points, if a site is using SSL, cachefile.net won’t do https right now. This will result in a browser-side notification / error. This is something that needs to be fixed; on the other hand, best practices are such that you should never reference external resources on an SSL-secured site anyway. As for cross-site script attacks, these are standard popular libraries only, no one will be uploading Javascript scripts to the repository (except me, or other admin people).