I have been looking for ways to use pathnames as an abstraction of network
file access as well as local files, which I believed was their intention.
I would primarily like to know how the designers of the pathname envisioned
the `host' part of pathnames be used. secondarily, if what I have in mind
is not unreasonable, I'd like to know if anybody have implemented anything
that could be seen as a "virtual file system" underneath pathnames such
that one could plug in, say, HTTP, FTP, or some other/proprietary protocol
and associate them with hosts, or perhaps devices (which also don't seem to
have any use in today's pathnames, despite the tradition (on old DEC
systems at least), to use logical devices instead of logical hostnames).
what I have in mind is not unlike GNU Emacs' ange-ftp package, which,
through an astonishing amount of specific support in the C substrate,
manages to provide a means to preempt the internal, local file system
interface. ange-ftp is based on recognizing a pattern in the filename,
specifically /[····@]hostname:[path], where []-parts are optional, but
this is clearly inferior to a standard, parsed pathname.
e.g., I would like a URL like http://www.naggum.no/emacs/index.html to be
equivalent to a pathname like that returned from the hypothetical call
(make-pathname :host "www.naggum.no"
:device "http"
:directory '(:absolute "emacs")
:name "index"
:type "html")
and that _something_ would implement HTTP and GET the file if read or POST
it if written. other file-system-like information can be read with HEAD.
ftp://ftp.gnu.ai.mit.edu/pub/gnu/emacs-20.1.tar.gz to become something like
that returned from the even more hypothetical
(make-pathname :host "ftp.gnu.ai.mit.edu"
:device "ftp"
:directory '(:absolute "pub" "gnu")
:name "emacs-20.1"
:type "tar.gz")
and _something_ would implement FTP and retrieve the relevant information
about the file with stuff like SIZE and MDTM in addition the standard
RETRieve and STORe commands.
any ideas?
#\Erik
--
mainstreme, adj. fanatically opposed to anything at all unusual
In article <················@naggum.no>,
Erik Naggum <······@naggum.no> writes:
> e.g., I would like a URL like http://www.naggum.no/emacs/index.html to be
> equivalent to a pathname like that returned from the hypothetical call
>
> (make-pathname :host "www.naggum.no"
> :device "http"
> :directory '(:absolute "emacs")
> :name "index"
> :type "html")
>
> and that _something_ would implement HTTP and GET the file if read or POST
> it if written. other file-system-like information can be read with HEAD.
>
> ftp://ftp.gnu.ai.mit.edu/pub/gnu/emacs-20.1.tar.gz to become something like
> that returned from the even more hypothetical
>
> (make-pathname :host "ftp.gnu.ai.mit.edu"
> :device "ftp"
> :directory '(:absolute "pub" "gnu")
> :name "emacs-20.1"
> :type "tar.gz")
>
> and _something_ would implement FTP and retrieve the relevant information
> about the file with stuff like SIZE and MDTM in addition the standard
> RETRieve and STORe commands.
>
> any ideas?
>
> #\Erik
I would think overloading the device field with the access protocol is a bad
idea. There are still filesystems around that have devices as part of a
pathname. (Like maybe DOS's C:?) I'd think a better approach would be to
"subclass" pathname into http-pathname, ftp-pathname, ... and then shadow
parse-namestring so that it could also parse ftp and http pathnames.
In CMUCL:
* (setq path #p"titian:/usr/people/mikemac/3c59x.c")
#p"titian:usr/people/mikemac/3c59x.c"
* (describe path)
#p"titian:usr/people/mikemac/3c59x.c" is a structure of type PATHNAME.
HOST: #<COMMON-LISP::UNIX-HOST {503FFFD}>.
DEVICE: NIL.
DIRECTORY: (:ABSOLUTE #<SEARCH-LIST titian> "usr" "people" "mikemac").
NAME: "3c59x".
TYPE: "c".
VERSION: :NEWEST.
* (defstruct (http-pathname (:include pathname)))
HTTP-PATHNAME
* (setq http-path (make-http-pathname :name "3c59x" :type "c" :version
:newest :directory (pathname-directory path) :host (pathname-host path)))
#p"titian:usr/people/mikemac/3c59x.c"
* (describe http-path)
#p"titian:usr/people/mikemac/3c59x.c" is a structure of type HTTP-PATHNAME.
HOST: #<COMMON-LISP::UNIX-HOST {503FFFD}>.
DEVICE: NIL.
DIRECTORY: (:ABSOLUTE #<SEARCH-LIST titian> "usr" "people" "mikemac").
NAME: "3c59x".
TYPE: "c".
VERSION: :NEWEST.
You'd probably want to write an appropriate print routine for them too.
You'd also need to shadow some of the functions on pages 637-638 of CLTL2.
Then I could do fun things like:
(with-open-file (fp "ftp://ftp.gnu.ai.mit.edu/pub/gnu/emacs-20.1.tar.gz"
:direction :input)
(read-byte fp) ...
)
Mike McDonald
·······@engr.sgi.com
In article <···············@infiniti.path.berkeley.edu>,
Marco Antoniotti <·······@infiniti.path.berkeley.edu> writes:
> ·······@SGI.com (Mike McDonald) writes:
>
>>
>
>> * (setq path #p"titian:/usr/people/mikemac/3c59x.c")
>>
>> #p"titian:usr/people/mikemac/3c59x.c"
>> * (describe path)
>>
>> #p"titian:usr/people/mikemac/3c59x.c" is a structure of type PATHNAME.
>> HOST: #<COMMON-LISP::UNIX-HOST {503FFFD}>.
>> DEVICE: NIL.
>> DIRECTORY: (:ABSOLUTE #<SEARCH-LIST titian> "usr" "people" "mikemac").
>> NAME: "3c59x".
>> TYPE: "c".
>> VERSION: :NEWEST.
>> * (defstruct (http-pathname (:include pathname)))
>>
>
> Note that this example uses the unportable SEARCH-LIST feature of
> CMUCL.
>
You're looking at the internals of the system's pathname implementation. I
only used the interfaces defined by CLTL2. How the lisp system, cmucl
in this case, fills in the slots as a result of parse-namestring isn't my
concern. When you shadow parse-namestring, at some point in your new version,
you should call the old version and extract out the pathname fields and put
them into your new http or ftp pathname. If you look farther down in the
example, that's essentially what I did by hand.
Mike McDonald
·······@engr.sgi.com
·······@SGI.com (Mike McDonald) writes:
>> * (defstruct (http-pathname (:include pathname)))
In case no one has mentioned it, you can't rely on type PATHNAME to
be a structure class. In some implementations it won't be and you
won't be able to include it as a parent type for DEFSTRUCT.