On Sun, Apr 19, 2009 at 10:18 AM, Lukas Renggli <renggli@gmail.com> wrote:
Serving files seems to be very confusing, as there are so many driving
forces and requirements.
1. The filename. There are two filenames, the one of the structure and
the one of the uploaded file. To me it is not clear which one is
preferable to be used? The one of the structure changes when the file
is renamed, the other one is determined by the original filename of
the upload.
the extension is sometimes cruical, since windows uses it to offer a program that can open it. Can structure names end in .doc?
2. The serving. There are two ways to serve files. Serving can either
happen using Seaside (the default) or using Apache (which is much more
efficient). The two approaches have completely different semantics, in
the Seaside case we have full control over the path. The approach with
Apache is limited to how Magritte lays out the files to the
file-system, however that could be fixed using X-Sendfile, but then
requires a non-standard plugin in Apache.
it would be ideal if the same image could be used in both scenarios. In one file would be served from the pier image, for instance when designer is working on his local copy based on one-click image. In other scenario web proxy would intercept file requst by recognizing url patttern, and serve the file it self.
For second scenario to work, there are two important conditions:
- all structures that need to be served as files need to have some recognizable url like /seaside/pier/content-files/*
- pier should also write uploaded files in equvalent file system directory structure so nginx or apache could serve it of from there.
Maybe there are even more possible dimensions. Anybody has an idea how
to consistently resolve these problems?
I think I have managed to add some more complications with my wishes ;)
rush