Generic interface to filesystems
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 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 ->email@example.com 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/
-----BEGIN PGP MESSAGE-----
-----END PGP MESSAGE-----