Loosing file name dowloading PRFile

[Davorin Rusevljan]

On Sun, Apr 19, 2009 at 10:18 AM, Lukas Renggli <renggli at 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
http://www.cloud208.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.iam.unibe.ch/pipermail/smallwiki/attachments/20090419/620c6f80/attachment.html>