Generic interface to filesystems

[Luca Pisati]

  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.
  
Exactly.  We should look more to file-systems where the concept
of "what is this file" is more developed than in Unix.  I have no
problem in using Unix as the low-level system, but I have troubles
thinking of Unix as a well designed file-system for associating
types to files.  Here is where ANSI-CL is also weak, since it
relies on a concepts (the extension) which shows its age.
MacOs and BeOs (among the commercial OSes) look definitively
more mature and interesting to me.

  ;; 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/