[Mailman-Developers] Re: [Zest-devel] Re: Pipermail replacement? Zest!

[David Champion]

On 2002.02.26, in <87sn7npty8.fsf@tleepslib.sk.tsukuba.ac.jp>,
	"Stephen J. Turnbull" <stephen@xemacs.org> wrote:
> 
> Er, all of them?  Search engines don't do authentication, webservers
> do.  Or at the very least, webservers can do enough kinds of
> authentication that you should be able to find one you like.

It's not a matter of finding an authentication method I like. It
has to be authentication against the Mailman list roster and its
passwords, whether or not I like it. :) I have that now, and actually,
it's provided by Mailman and its integrated archiver, not by the HTTP
server. If I add in a search engine, it needs to link into the same
authentication system, and work in the same way. The HTTP server can't
do that.

I've slipped a semantic boundary by speaking of the MLM and the archiver
as a unit (they are, to some extent, but the roles are separate and they
don't have to be integrated). Maybe it's been a little unclear what I'm
getting at.

The current situation (archiving with no indexing, authenticated
against the MM rosters) is possible because the archival documents
on disk are accessible only to the Mailman CGI modules, and those
authenticate access by being a core part of Mailman. So when I throw
in an indexer/search engine, how will I make it authenticate against
Mailman, too?

I can achieve that by hacking onto an existing search engine knowledge
of Mailman, which sounds to me like a PITA and difficult to support
for any length of time (since the search engine isn't really bound to
Mailman in any significant way).

Or I can achieve it by using a search engine whose search parameters
are taken as a GET request in the URL, so that it's visible to the web
server, and munge into the web server recognition of the GET string
so that it can authenticate to Mailman's roster using a substring of
the URL passed through some arcana that I'd have to code up as an
independent authentication module, I guess. But that sounds even worse.

Or, since the archiver is an integrated part of Mailman already -- this
is presupposed in the context of this thread -- I can have the archiver
perform some basic searching. That's easy on the user, because it's a
single authentication transaction to get into the archive and to perform
a search. (With the other approaches, it's two transactions, unless the
new code knows not only how to talk to Mailman's roster, but also how
to insert an authentication token into the HTTP client in a forward-
compatible way.) That's also a bit of work, but it doesn't need to be
high-powered searching. Just basic "find this text" will do for most
purposes. And it has the advantage of being more integrated with the
MLM, requiring less off-sync third-party maintenance. I'm interested
in a 95% solution. And it's there and useful with environments besides
Mailman, too, even if they also use odd built-in authentication systems
that aren't a part of the local web server.

Maybe I'm still missing something, but if so, I still don't see it.
That's how it seems to me. Anyway, I'm only trying to show that there's
a case for having the search capability in the archiver, not to say that
things should or shouldn't be some particular way.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago