Alexander Genaud wrote the following I am just posting it here:
There are two components: The Indexer and
the Searcher. The Indexer need only be run
once (on John's machine, perhaps). This
generates the index which allows very fast
searches at a later time.
The Searcher is loaded into the browser as
an applet. It reads the index (directory)
from the local media and performs the query
from the user input against the index. We
then generate a temp HTML file on the local
harddrive containing the search hits. We
then tell the browser to open the temp file
in the active window.
The applet must be signed for all of that
to work (read/write permissions). The
application can simply bypass all the
security restrictions, but because it is
not running in a browser window, it has to
jump through hoops to open the temp HTML
file in the default system browser.
All of that works (less or more). However,
it's at that level that keeps me from supporting
a few browser/platform combinations. IE/Mac
comes to mind.
You'll notice that for very obvious
queries, the HTML file is quite large
and takes a bit of time to generate and
load in a browser. This isn't necessary at
all. However, the alternatives are interesting.
(1) Generate multiple pages with 10-20 hits
per page. (2) Generate one page with 10-20
hits and embed the applet in that page, add
(next, previous) buttons in the applet and
requery and retrieve the appropriate hits. I'm sure
you could come up with others.
Of course, there are a bunch of cosmetic features,
that I'm not ready to care about yet (feel free
to implement them) such as "return key" instead
of searching after a button click. This list is
While not (yet) required by ATI, I'd like to get
this Unicode compliant.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.