Skip to main content.
home | support | download

Back to List Archive

Re: swish.cgi

From: Bill Moseley <moseley(at)not-real.hank.org>
Date: Tue Dec 04 2001 - 15:19:48 GMT
At 01:55 AM 12/4/2001 -0800, Alex Lyons wrote:

>I'd be interested to see if you could duplicate the functionality of 
>your current swish.cgi Perl script (snippet highlighting, sorting by 
>property, etc) using the SWISHE module interface rather than forking the 
>swish-e executable.

Ya can't win!  This makes me smile because my original script (swish2.cgi)
used a module I wrote called, simply, SWISH (this is different from the
SWISHE module included in the distribution) and is on CPAN.

The idea of the SWISH module is the exact same interface can be used to
access swish via forking or with via the swish-e C library (like using the
distribution's SWISHE module).  The plan was also to make it interface to
the swish-e server (whenever someone magically appeared with one).

It's a cool idea since if you want to change from forking to the C library,
you install the CPAN SWISH::Library module, and change one word in your
script (from Fork to Library).  Kind of like DBD in the world of DBI.  But,
like DBI, how often would people really change?

Again, what happened with that script is that people complained that it was
too hard to get going -- people didn't like installing modules from CPAN
and it was just plain too time consuming to get a little CGI script running.

I do know that a number of people are using the SWISHE module to interface
directly to the swish-e library.  The advantage of this method should be
speed since it avoids the forking of the CGI script.  But in some simple
tests I didn't find that it is that much faster, especially if running
something like a perl CGI which has large startup cost.  Benchmarks welcome.

I also tried it under mod_perl, which avoids the startup costs, but then
you are buying speed with memory by duplicating the swish-e library and
data structures (which are not shared) in RAM.

Anyway, there's no easy solution.  I really understand the need for a very
easy to install, yet full-featured script.  People seem to be able to
install a single CGI script, but if there's one additional module
requirement then it seems to weed out a lot of people.  But that really
promotes writing ugly, non-modular code.  My life would be easier now if
someone would have forced on me from the beginning mod_perl, DBI object
abstraction, MVC design, and a good templating system.  No wonder Java is
so successful.

Maybe I do need to support more than one CGI script.

swish.cgi 
  -- works out-of-the-box, no module requirements

swish2.cgi 
  -- requires the SWISH modules to abstract the calls to swish, and
     uses HTML::Template for presentation layer

swish3.cgi
  -- same as swish2.cgi, but uses Template-Toolkit for presentation.

Still, that's a bunch of code duplication.  I actually use swish3.cgi -- it
was really trivial to convert swish.cgi to swish3.cgi, so maybe it's a bit
overboard to supply so many options.

The basic problem is that a swish.cgi script needs to be modular.  There's
more than one way to call swish, more than one way to show results, and
there's more than one way to do term highlighting.

Bill Moseley
mailto:moseley@hank.org
Received on Tue Dec 4 15:20:39 2001