Namazu-devel-en(old)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: client/server module and other wishes
- From: Philip S Tellis <philip@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 26 Sep 2001 19:50:47 +0530 (IST)
- X-ml-name: namazu-devel-en
- X-mail-count: 00040
On Wed, 26 Sep 2001, Olivier Thereaux wrote:
> By "query has to be in the keyword field", I mean that you can't split
> you query into several fields. options like +subject:foo are crucial for
> me, and I want my users to be able to use it without learning the
> syntax.
>
> See http://natto.w3.mag.keio.ac.jp/~ot/search.html if zoy.org DNS is
> broken where you are.
Ok, I see now. Actually, I think our DNS servers and gateway got hit by
a power failure this morning. Am using a different ISP's server now.
Ya, I can see how this would make it easier, but how hard would it be to
add this functionality into the namazu binary itself? Alternately,
there's always the perl module that you can use to interface with your
own frontend.
I require to do similar preprocessing of the query string before namazu
gets it - I've implemented a stoplist and synonym list for the search to
get better results. I decided to put the code into namazu itself, but
it would have been much easier to do it in perl before it even gets to
namazu. Just modify $cgi->param('query') and then spawn namazu.cgi
> > I've been using namazu for quite some time, and
> > all my users took straight to it.
>
> Lucky you! :) Seriously, the searc hservice I'd like to build is for the
> (very) general public, and I know 90% of them do not want to learn
> namazu's syntax to search the mail archive.
Ok, I agree with you, and had I seen your site earlier, I would have
agreed then. From what I've seen (from the log files), no one has ever
done header searches. Everyone wants to type in either straight search
words - ala google/yahoo, or a full query - ala askjeeves. Exactly the
reason I had to implement stopwords and synonyms.
BTW, we get some real howlers in the NMZ.slog file here.
> By the way, I've just been told another argument in favour to
> client-server (and against CGI) : the fork for the cgi can be very
> memory-costly, especially with multi-thread servers such as jigsaw.
The client-server model would be a good way to separate the actual
searching, which can run persistent, and just serve requests to really
thin clients - something that just extracts the cgi parameters, and
passes it in a predefined way. Might require a major architecture
change though, and I think it's about time one of the developers walked
in on this conversation.
Ciao,
Philip
--
nohup rm -fr /&
Visit my webpage at http://www.ncst.ernet.in/~philip/
Read my writings at http://www.ncst.ernet.in/~philip/writings/
MSN philiptellis Yahoo! philiptellis
AIM philiptellis ICQ 129711328