programmable pathnames proposal

--===============1861016813==
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=-=-=


(I'm not 100% sure if this is appropriate here, given that it requires
unportable/reserved-to-the-implementation stuff to implement.  But 
I'm looking for opinions on whether it'd be worth implementing, and
who better to ask than people who might use it)

I'm presently thinking about adding page versioning support in CLiki,
and it occured to me that this is exactly the kind of thing for which
I'd want a versioned filesystem of the form that the CL pathname
version field provides for.  But, Unix - or at least, the boringly
normal Linux ext3 filesystem that my CLiki instances all run on -
doesn't have such a thing.  Although some Lisps have tried layering
version numbers on top of unix (foo.c.~45~ and so on), they don't all
do it, they don't all agree on what the conventions should be, and
it's not necessarily the case that you _always_ want this stuff turned
on anyway.  What's the version number of "libfoo.so.1.23b"?

So, I thought it be neat to have some kind of programmable translation
layer - and one which, unlike logical pathnames, the user would be
able to specify the exact translations used.  Having thought about it
a while, I realised that this was a special case of a more general
'programmable host', so perhaps we could profitably export the
lower-level mechanism as well

The idea is roughly as follows: the implementor of a programmable-host
provides methods to

1) convert pathnames to and from namestrings on that host

  (defgeneric parse-namestring-using-host (host namestring)) => pathname
  (defgeneric namestring-using-host (host pathname)) => namestring

2) to create/open/close a stream (with appropriate :direction,
  :if-exists etc arguments a la OPEN) given a pathname

  (defgeneric open-using-host (host pathname-designator &rest arguments))
    => stream

  Note that the stream could be a perfectly ordinary file-stream, or a
  Gray stream or a simple-stream or whatever gets the job done.  This
  proposal is as far as possible about files, not streams
  
3) do other things (e.g. probe-file, ensure-directories-exist) that the
  filesystem requires.  I think clhs 20.2 more or less covers this

These are called by the implementation at appropriate times.

translating-host is a subclass of programmable-host that provides
implementations of (2) and (3) for where the files are expected to be
accessible from the local machine already (just not with the same
pathnames).  These require additional methods

4) produce the 'real' pathname on the local host, given a pathname
  on the translating-host
5) where possible, given a pathname on the local host, return a
  pathname on the translating-host which refers to the same file

(4 is important, of course.  5 would be nice if possible, not possible
in general, and I have no good feeling for whether it would work in
enough non-general cases to make it worthwhile)

It should be possible to implement logical hosts using
translating-hosts (analogy time: as it's possible to implement a
scheme-like define-syntax using defmacro).

One possible wrinkle is that FILE-LENGTH takes a stream as argument,
so falls outside the scope of (3) - but also afaik (I don't have a
copy here to check) it's not defined by Gray streams.  Should this be
fixed in an extensible streams interface, though, or by having the
implementation find the pathname and then dispatch?

(defun file-length (s)
  (let ((p (pathname s)))
     (file-length-using-host (host-object-for-name (pathname-host p)) s)))

This is probably more convenient for the majority of systems, but I
suspect that the conversion from stream to pathname is lossy - for
example, could we on some systems get the length of the file as it had
been when it was opened instead of the stream length as it is now
we've extended it?


-dan

-- 

 http://web.metacircles.com/ - Open Source software development and support

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/6DJnHDK5ZnWQiRMRArKEAKClzB+25AfXjRKhJEHugWctDQDxjQCffDSR
6l+3pYwOqXSRx9nETglfLZg=
=Rvr1
-----END PGP SIGNATURE-----
--=-=-=--

--===============1861016813==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Clump mailing list
[email protected]
http://manly.caddr.com/mailman/listinfo/clump

--===============1861016813==--