Generic interface to filesystems

cwg@DeepEddy.Com cwg@DeepEddy.Com
Sun, 04 May 1997 22:05:00 -0500

Content-Type: text/plain; charset=us-ascii

>   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.

Sorry.  I didn't really mean dwim in the sense that you're reading it.  Mea 
culpa.  I merely meant having some heuristics for determining what in the hell 
is inside a file that happens to be stored in a Unix filesystem.  Once someone 
has written an OOFS, these heuristics would become unnecessisary.

>   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.

Agreed 100%.  I think we need to be able to read from arbitrary sources of 
information (anything that a URL can point to), but we also need to have a 
storage system that is truly Lispy in nature.

>   ;; 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).

BROWSE is a better name thay DISPLAY, so we've got our first required method 
for these objects.

(browse (read-object (parse-pathname "~cwg/Mail/Misc/lispOS")))
  32   Fri  <-Martin Cracauer Re: Running Unix programs under LispOS
  36   Fri  <-Fare Rideau     UserLand & Kernel efforts: complementary, not op
  37   Sat  <-Mike McDonald   Time to get busy!
  44   Sat  ->Mike McDonald   Re: Time to get busy!
  47   Sat  <-Kelly Murray    Re: Time to get busy!
  48   7:29 <-Fare Rideau     Oomph
  49  16:39 ->Fare Rideau     Re: Oomph
  50  16:41 ->Kelly Murray    Re: Time to get busy!
  52  17:13 ->lispos@math.gat Generic interface to filesystems
  54  17:55 ->Adam Alpern     Re: Generic interface to filesystems
  65+ 20:23 ->Luca Pisati     Re: Generic interface to filesystems
  66  21:08 ->Luca Pisati     RE: pathnames

With all those lines appearing in a window, if that's our metaphore and 
certainly with all those lines being clickable.  (also the arrows being real 
arrows, but that's real minor.)

Okay, if someone can write read-object so that it's got the hooks whereby I 
can tell it that anything in a unix path that looks like 


must be an Mhfolder, then all I have to do is to attach my (as-yet-unwritten)
object to those hooks and I'm done.  SMOP.


Chris Garrigues                    O-              cwg@DeepEddy.Com
  Deep Eddy Internet Consulting                     +1 512 432 4046
  609 Deep Eddy Avenue
  Austin, TX  78703-4513              http://www.DeepEddy.Com/~cwg/

Content-Type: application/pgp-signature

Version: 2.6.2