David C. Martin (
Mon, 19 Jul 1993 09:07:03 PDT

Exactly. However, you would like to separate the two functions as it
would allow you to index information contained in various objects
(files, etc...) and then utilize that index to return some compilation
of those objects or some other object (e.g. indexing a database of faxes
utilizing the OCR text, but actually returning the fax, not the OCR text

Martijn Koster writes:

> On a related topic, at IANET in Pittsburgh, Jim Fullton & others came
> to a general consensus that it'd be nice to allow WAIS to separate
> indexing from retrieval -- the upshot would be that WAIS could, in
> response to queries, return URL's and URN's that do *not* necessarily
> correspond to documents within a traditional-style WAIS database.

I think I'm a bit confused about the current WAIS debate.
In the above case you get URL's back. Unless you have a WWW browser they
are no good, so I assume you are using a WWW browser to send the searches.
Then where does the need for WAIS come in?

Can you not achieve the same thing by having waisindex generate an index
of a file with titles, keywords and URL's, and have a command line WAIS
client called from the HTTP server, or compiled into the HTTPserver do
the lookups? This would eliminate the need for the WAIS protocol, and in
effect you only use WAIS's impressive search performance as part of your
server implementation. If you then educated the server about say a suffix
indicating a WAIS index file you would have a really flexible capability.

I have been thinking about doing this for the Mac Archive, but as I know
nothing about WAIS, a Perl script will have to do for now...

Am I missing some vital bit of insight?

-- Martijn
X-400: C=GB; A=Mark400; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NeXor Ltd@cn=Martijn Koster