From: "Jerome Alet" <alet@unice.fr> [snip]
Our needs are to store hundreds, and possibly thousands of MPEG2 and MPEG4 (generally short) video movies, MP3 audio files, JPEG images, etc...
[snip]
I see 5 solutions:
1 - store both files and their associated datas in ZODB 2 - store files in the filesystem and datas in ZODB 3 - store files in the filesystem and datas in an RDBMS (use Zope only for the presentation of files and datas) 4 - store files in ZODB and datas in an RDBMS. 5 - don't use Zope at all because it's not appropriate.
In general, large file uploads thru HTTP are clumsy. The browsers don't provide progress indicators. Broken connections occur due to timeout under network congestion but the browsers don't handle broken connections well. And (as far as I can tell) the entire request (including the entire file) is buffered in the OS swapspace. Some site I saw recently (was it xdrive? I'm not sure) uses client-side Java to manage the upload. I chose #2 for a similar application and ran into these additional issues: 1. A file upload done thru Zope into the filesystem passes thru a temporary file. This increases slightly the apparent upload time, while you copy the file to its final destination. And, you must also ensure that the partition where temporary files are placed has enough space for the maximum file size. 2. You must also decide how you are going to serve the file. Since it's in the file system, you could serve it directly thru Apache (perhaps thru a redirect initiated by Zope), thereby avoiding occupying a Zope thread for a long time for every downlaod. But if you take this approach, you must somehow make Apache apply the same access control to the file that you have in Zope. This can be done, but is an added complication. -- My .02 -- Loren