[Zope] [announce] Local File System product

Jonothan Farr jfarr@real.com
Mon, 25 Oct 1999 18:12:12 -0700


> Issues to address:
>     security (not as much of a problem as with my read/write product)

The only security issue I've addressed is that '..' is not allowed as a
directory name, it will throw a ValueError. Also, of course the Zope server
has to have permissions to access any files that it tries to read through
LocalFS. If anyone can think of any others please let me know.


>
>     filtering -- e.g. I want to see only .HTML files (easy)

It should be pretty easy to write a DTML method to do this, using
methodBrowse.dtml as a reference. To use this right now you would have to
inherit the method from a folder above the file system object (or hack the
source). I thought about making the file system object a container just so
you could add your own methods and such. The problem is that any objects
contained by the file system object would potentially mask files in the
local file system, so I decided against it.

>
>     content-type -- why does everyone have to reinvent mime.types?
>         Apache, Python, Zope (File/Image), Confera, Squishdot, and LocalFS
>         each has its own hard coded set of favorite mime types that get
>         recognized by suffix.
>

LocalFS actually uses that standard Zope mechanisms for determining the
content type. It just lets the Image.File or Image.Image object figure out
its own content type. I did add a hook for overriding the content type with
a static list because 1) I didn't like some of the content types that Zope
was deciding on, i.e. application/octet-stream for .rm files, and 2) I plan
to make this a feature of the user interface to allow administrators to
override content types.

>         Maybe someone (maybe me) could create a mime-types product that
solves
> this
>         problem once.  The client could point to a preferred
type-registry, a
> file name,
>         and the first 200 or so bytes of the content, and get back a mime
> type, a
>         human readable name, and a set of icons.

I like that idea. Go for it!

>
>
> possible future extensions:
>
>     Uploading files to the file system.
>
>     redirects -- e.g. for large multimedia files
>
>     access to application-level file systems -- e.g. zip|tar|cpio files,
CD
> images, IMAP folders
>            this could be done by abstracting the file system in a way
similar
> to
>            ZServer/medusa/filesys.py.
>
>

Those are some great ideas! Thanks for all the feedback.

-jfarr

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi! I'm a signature virus.
Copy me into your .sig to join the fun!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~