Drupal Association members fund grants that make connections all over the world.
Drupal needs to abstract the URL generation process of files in a standardized, everywhere: from page.tpl.php to modules, to drupal_add_css(). That allows us to serve files from different servers.
The benefit is that Drupal can then rewrite file URLs to be served from static file servers or CDNs, FTP servers, or even bittorrent. However, in many cases there's a delay between a file being available on the Drupal site (i.e. the web server), and the synchronisation of that file to a file server. So we need to automatically fall back. E.g. try the CDN, if it's not available there, try the static file server. If none of the stand-alone file servers can serve the file, use Drupal's web server (which is *always* the file server currently, in Drupal 6 and earlier).
The first step is to allow pluggable file server types. This can be done through hook_file_server(). In short: each module that implements this hook should keep a local "source file - destination file pairs" cache, return the destination URL in case it's in the cache, and otherwise return FALSE.
The second step is to allow the user to configure the file server order (see the attached annotated screenshot): which file server should be preferred (i.e. tried first), which second, and so on. The web server Drupal is running on, will always be the last preferred server, i.e. the file server to which always can be fallen back.
Step three finally, is to abstract the URL generation and to implement the fall-back mechanism. This is file_url() function, which iterates over the available file server hook implementations, stopping when it receives an URL, trying the next file server when it receives a boolean FALSE. If none of the file server hook implementations returned a URL, Drupal's web server will be used.
This patch allows you to create scalability-enabling modules like the CDN integration module that I wrote.
Attached is a patch against Drupal 5 core. I want to get feedback before porting this patch to Drupal 6 and thus getting to the point where I have to maintain core patches for multiple Drupal versions.