Re: how should remote path names be handled?

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Edward Vielmetti: "Re: support for setext, the structure-enhanced text format, in WWW "
• Previous message: Guido.van.Rossum@cwi.nl: "Re: support for setext, the structure-enhanced text format, in WWW "

Date: Mon, 26 Apr 93 10:12:27 MET DST
From: timbl (Tim Berners-Lee)
Message-id: <9304260812.AA21735@ nxoc01.cern.ch >
To: bloemer@tnt.uni-hannover.dbp.de, fine@cis.ohio-state.edu,
        timbl@nxoc01.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: how should remote path names be handled?

This is one of the ways inwhich I an unhappy ith the WAIS-WWW interface.
The WAIS docid is by design a string which should be opaque -- that
it does not hve any client-visible features like / ina URL to allow
relative pathnames. In fact, of course, all it really needs is the
file name, and the document type.  These could be put in in plain.
In fact we have to treat it as an opaque string, almost.We do 
make the assumption that it is a set of numbered fields. This is already
breaking the spec.  We can't assume what those fields are as from time
to time you find an experimental WAIS server weird numbers (which used
to crash the old gateway).

The solution as I see it is to dismantle the freeWAIS code a little
more and make a W3 server which will sit on top of the index
and return real pathnames.

(or you could cheat and run a W3 server which served up the files,
and also was the wais gateway, and change HTWAIS.c so that instead
of returning WAIS URLs it returned URLs pointing to itself as an HTTP
server. The code would not be able to access other WAIS servers but
itwould avoid changing any WAIS code.  Themapping from WAIS URL
to HTTP URL would have to take into account the rule file, or the
rul file would have to avoid mapping between docids and filenames  :-(


Tim BL