Generic interface to filesystems

[Adam Alpern]

Chris Garrigues sez:
;; I'd like to start this message by observing how often a mention of a good idea 
;; on this list seems to be followed by someone saying, "that's been done in xxx 
;; in such and such a way".  Therefore, it seems to me that the
;; important thing 

Often, that's because if a project of this scope is ever going to get
off the ground, given the mass bias against the Lisp family of
languages, we have to leverage existing standards (and interoperate
with other standards, like CORBA - but that's a whole 'nother thread )

;; I want a function that takes a path as an argument and returns an object 
;; corresponding to the file referenced by that path.  This object would not 

[ examples snipped ]

An excellent idea - we must make sure to keep a logical separation
between modules however. This is something that can independent of your
pathname representation, assuming the pathname representation isn't
braindead. 

This would be the perfect thing to be part of a translation services
package.

;; There would need to be quite a bit of DWIM to figure out from extensions and 

Minor comment - I think DWIM is evil. Gabriel's history of LISP has
some examples of what was valid code after going through the spelling
checker and DWIM in Interlisp. Pretty hideous stuff could get parsed
as valid code. Most attempts at DWIM that I've seen weren't
predictable enough. If you're ever going to infer meaning from the
users actions, you should have VERY rigid rules that NEVER have
exceptions, or you'll have a lot of bloody feet.

;; other hints what each file is supposed to be (The MIME type, if read via HTTP;  
;; the extension for Unix files;  the owner/type files for MacOS files;  the fact 
;; that it's in /var/spool/mail or has name Mail;  etc.).  There also should be a 
;; keyword parameter to overwrite the DWIM.

Parsing by filename extension is really not reliable. What if you have
a directory name with a period in it? This is a good argument for
high-level information in the filesystem. The MacOS did pretty well
with type/creator codes. The BeOS has an integrated database which can
associate arbitrary information with any filesystem reference. (BTW, I
think everyone should look very closely at the BeOS - there are lot's
of neat ideas there.) MIME types are a reasonable standard. Again with
BeOS - its DR9 filesystem uses MIME types to identify files and map
between files & applications. They've got extensions for the "owner
application" as well.

;; If we can agree on methods like "display", it would then be easy to write a 
;; filesystem browser that knows all about all the different objects (and I could 

I wrote a large blackboard system development environment in Macintosh
Common LISP. Every object that could be visually represented had a
#'browse method, so the user can always look at any object, without
needing to know anything about (insert massive plug for CLOS here).

-Adam

--
Adam Alpern, <alpern@brightware.com>
http://www.brightware.com/~alpern/