After poking at it during the weekend while not playing with the kids, I found one reason to prefer SWISH++ over SWISH-E as it exists today. Phew as in stinky code! As in, I completely understand the comments from the SWISH++ author as to why he needed to rewrite the original SWISH.
It may be the past year's experience with AOLserver has left me with high expectations regarding open source coding, but the basic SWISH-E code is poorly commented, poorly structured, and has no separation of anything. No separation of search client from index client (it's the same program with different parameters), no separation of library interface headers from actual headers. There's no encapsulation.
Maybe I'm missing the point, but their "search" interface is evidently not a read only operation, making the developers believe that an opened index can't be searched from simultaneously from two different threads.
I'm going to spend another day or so playing with it and will most likely use Rob's threadpool services to make a AOLserver friendly, stable, encapsulated interface. Why? Because if they're doc is to be believed, the basic system does appear pretty powerful.
If worse came to worse, and search was good but crashed aolserver a few times per day, I would consider just creating an aolserver/swish standalone webserver. That is, isolate it completely from the aolserver/acs server, and use a variety of techniques to communicate with it (ns_httpget or XML) and other techniques to restart it when it croaks.
Well it's open source right? (I.e., I won't complain too much, I will see if I can make it better with a reasonable effort.)
