mapping files to objects

[Luca Pisati]

cwg@deepeddy.com wrote:
> 
> 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
> necessary.
> 
> 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
> classes.
> 
> (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).
> 
> Comments?

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
> 
> --
> 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:    pisati@nichimen.com
Los Angeles, CA 90066          Web:      http://www.nichimen.com