Okay, here is what I propose (and what I'm actually doing for a client). Everywhere I see "cr_write_content" I will have a redirect to download the file using file.vuh (unless it does more than just return a file, obviously).
For file.vuh to work with this the following changes are needed:
a) It needs to work both with revision_id as well as item_id. At least this would be my understanding that you can call /file/1353 and it does not matter if 1353 is an item or a revision.
b) I set the content-disposition header in file.vuh, although this requires an additional DB query
For the client I will not use cr_write_content though but use NGINX and X-Accel_redirect to serve the physical file directly from the harddisk (content-repository-content-files), bypassing AOLserver. I will write this up in my NGINX documentation.
I won't touch view.vuh in OpenACS, just for the client.
If you feel the above change to file.vuh (and image.vuh ?) requires a TIP, let me know, otherwise I would commit after the weekend when I'm done to HEAD (or should this to go to 5.4 ?)
