Forum OpenACS Development: Re: File Storage and Relative Links

Collapse
Posted by Malte Sussdorff on
Some of my thoughts after talking to Carl and Ernie

a) User goes to file-storage and says: I have this zipfile, please upload me to this MountURL. When I say MountURL it does not mean, that we would mount an FS instance there. It just says, I will find all the files relative to this MountURL. Challenge: Make sure the MountURL does not conflict with a mounted package.

b) OpenACS takes the zipfile, unzips it and stores the files in the content repository analogous to Photo Album. In addition it will make an entry to a mapping table (unless there is a cleaner way), containing (file_name, MountURL (ID?!?), cr_id, mime_type). I know that we store some of that information already somewhere else, so a simple MountURL, cr_id table could be sufficient, but I'm not so sure performance wise. Using a MountURL_id has the advantages of beeing able to quickly change the mount_points, without the need to run an upgrade on the mapping table.
Challenge: Subfolders in the zipfile. If we allow subfolders (and can actually deal with them), we can either make it easy and store the relative path (with regards to the MountURL) with the filename. So, if you upload a zipfile that contains /pictures/malte.jpg, the filename would be /pictures/malte.jpg, no change to the MountURL. The other (cleaner) option would be to dynamically create a new MountURL ($MountURL/pictures) and store this new MountURL along with the simple name of the file (malte.jpg).

c) A random striker hits http://mysite/MountURL/filename. The RP (or the FS module, see below) would look through the mountpoints for packages and then for the MountURLs of the file storage. I could imagine that we have to force the random striker to visit http://mysite/file-storage-mount-point/MountURL/filename. This way we would not have to make enhancements to the request processor.  After it detected the MountURL, it will go to the mapping table and grab the cr_id and mime_type of the filename associated with this MountURL.

d) Deliver the file :)

This might be a very simplistic view of the problem, but if the approach is right in general, we could start by nit picking on this view and add enhancements accordingly. And if this approach can't work at least we know it :).