mapping files to objects
Tue, 06 May 1997 11:08:36 -0700
> In the interest of getting something that is (a) implementable on top of the
> Unix file system and (b) has semantics that can be expanded to The Right
> Thing (tm) later, I'd like to make a modest proposal (no, we aren't going to
> eat our young).
> 1) Let's take the CL path objects and add the notion of a file type to the
> object. This file type would *not* appear in the printed representation of
> the path, but would instead by set and read by accessor functions. This type
> could then be mapped into a MIME type or a MacOS style owner/type pair.
> Initially, I thought it should be a MIME type, but then my stupidity passed
> and I realized that it should be a CLOS class. *duh*. This class would have
> a method for determining the MIME type or any other foreign typing system
> 2) Since a Unix file system doesn't have these semantics in it, let's define a
> facility which allows one to define mappings between Unix paths and the above
> defined classes. A similar facility should be defined between MIME types and
> (def-unix-extension-map "tar"
> :class 'tarball)
> (def-mime-type-map "application/x-tar"
> :class 'tarball)
> (def-unix-directory-map "/var/spool/mail"
> :contains-class 'mbox)
> (def-unix-filename-map "README"
> :class 'text-file)
> (def-unix-extension-map "lisp"
> :class 'lisp-source-code)
> lisp-source-code and mbox are probably built on text-file with additional
> methods for handling lisp source and the broken Unix mailfile format.
> 3) It now becomes nearly trivial to write the function that I previously
> proposed to map from a pathname to an object representing that file.
> 4) When/if we write our own file system, this can be implemented natively so
> that all files would have a class associated with them. Our file system
> wouldn't need real extensions so we'd do away with that baggage, but it should
> still support some form of soft deletion and versioning.
> 5) Even if we never develop a working Object-Oriented store, we're already
> well ahead of the rest of the universe in our file type information (and, most
> importantly, it gives me the hooks that I want to start writing a
> well-integrated mail system).
Yes. Did you ever look to how MacOs is capable to handle
MacOs files (resource fork + data fork) stored on an Unix system ?
The point being that, If we define that files (not pathnames) _do_
contain types and other properties, we could then take the same
approach MacOs does:
for each MacOs file there are really two files on the host system:
1 file for the resource fork, which makes sense _only_ to MacOs
1 file for the data fork, which can be available to any application
capable to understand the host file-system.
Example, a Lisp source file called foo would then be stored on the
host filesystem into:
foo.<lispos-resource> lispos relevant info as the file type
foo the ascii file
so that, every OS will be capable to use foo, but only LispOs
will take advantage of foo.<lispos-resource>.
When MacOs does this on Unix, you have the following situation:
if foo is under /my-disk/my-job/
then foo is store as /my-disk/my-job/foo and foo.<lispos-resource>
is stored as /my-disk/my-job/.<lispos-resources>/foo
> 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/
> Part 1.2 Type: application/pgp-signature
Luca Pisati Voice: (310) 577-0518
Nichimen Graphics Fax: (310) 577-0577
12555 W. Jefferson #285 EMail: firstname.lastname@example.org
Los Angeles, CA 90066 Web: http://www.nichimen.com