>The speed with which you could access, for example, 35 pages, parse the
>META information and present the search results to the browser would be an
>issue, wouldn't it?
It can be, especially if it's more like 3500 pages. I used a
solution that, admittedly, won't be appropriate
for many applications. One application that I use it for here is to
index resume of subscribers to our magazine. The Meta-Tags embedded in
the resumes contain info like modification date, expiration date,
subscriber name, etc... Since these fields are mostly short and
I created a <TITLE></TITLE> block for each resume that contains the
"qualification data" for each resume. For example, the title might read
to indicate that the subscriber is first name "Joe", last name "Blow"
and his subscription expires on November 30, 1999. (My actual usage
is a bit more complex, but that's the idea.)
This title is returned in the search results so there's no need to
actually open a file to find the value of the Meta Tag. The script
handling the Swish-e output can explode the title and then make
qualification/sorting decisions at that point instead.
I took it a step further and added a bit of code to Swish-e
itself so that (when appropriate parameters are specified) it
will only return search results that also match certain
elements of the title (like a last-modified date, for
instance). That gets the performance down to how fast the
script module can process the results.
A long answer to a short question, but maybe there are some
useful ideas in there. :^)
Received on Mon Nov 30 11:14:00 1998