Generic interface to filesystems

[cwg@DeepEddy.Com]

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

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 
that a LispOS project can provide is a way to make sure that all these great 
ideas that have been implmented (and will be implemented) work together.  
Therefore, we need to put some focus on how to define interfaces between the 
different pieces.

Now then...since I volunteered to write a mail reader/head a project to design 
and write a mail system, I've started to think about what hooks I'd like to 
have into the rest of the system.  Here's the first one:

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 
necesarily read the actual file at that time, but it would then have it's own
set of methods for doing whatever can be done with that kind of file.  It
would be critical to agree on methods for doing various generic 
things.

For example:

(read-object-from-path (parse-pathname "foobar.tar"))
#<tarball 12345>
(read-object-from-path (parse-pathname "/usr/local/src/README"))
#<textobject 54321>
(read-object-from-path (parse-pathname "/etc"))
#<directory 98765>
(read-object-from-path (parse-url "http://www.foo.com/"))
#<htmlobject 56789>
(read-object-from-path (parse-pathname "/var/spool/mail/cwg"))
#<mbox 24680>
(read-object-from-path (parse-pathname "~/Mail"))
#<mhfolder 86420>

There would need to be quite a bit of DWIM to figure out from extensions and 
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.

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 
embed my mail reader in this filesystem browser).  If the editor folks could 
agree on methods like "forward-item" to bind to c-m-F, it would be possible
to write an editor that handles *very* diverse objects.  It also allows the 
easy logical separation of the code that accesses the files from the code that 
processes the objects, so that a mail folder could be moved from the 
filesystem into a database without breaking anything.  If the implementor of 
the tarball were to use the same methods that are implemented for a directory, 
we could descend into a tarfile easily...and so on.

My task as the "mail guy" would then be:

a) A generic mixin for all mail folders which displays mail folders, allows
one to find subfolders and/or messages, and allows various other operations 
(moving messages, etc.)

b) A generic mixin for all mail messages which displays the message, allows 
one to reply to a message, etc, etc.

c) Mixins for various objects such as mhfolders, qmail Maildirs, babyl files, 
mbox files, which allows them to be accessed by the methods in the above 
mixins once they've been created by the read-object-from-path function.

So, in the spirit of my first paragraph, does this infrastructure already 
exist to be integrated into our system, or do we need to invent and design it
from scratch?

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/



--==_Exmh_1330521040P
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQB1AwUBM20J/5aQnaaFII2dAQG+XAL/WUthJAbo2izZxHp07KchDI8uUn8BPynP
vVJ71fUberCExtjQD/FLX3UGPGAZ89mghhYyLDAABULGd4F5hLJ7QNbTcl7Ud4W6
COB1p16/grEjIGV/xykIN2NQIzAS0R49
=9xgM
-----END PGP MESSAGE-----

--==_Exmh_1330521040P--