Re: [wmvs] Prerequisites, Minimum Versions, Platforms?

On Mon, 6 Sep 2004, Terje Bless wrote:

> >There were people announcing they got earlier versions of the Validator
> >running on IIS, for example. As far as `check` is concerned, anything
> >providing CGI support should work.
>
> It's a good chance that stuff like auth-proxying only works on Apache, which
> would mean that we're trying to be "generic CGI" but in practice we only work
> on Apache. That would mean we're limiting our options in «check» needlessly.

Hmmm?  None of us know IIS (unless Jim is listening:-).  Let those who
do deal with it.  Just don't knowingly breaking compatibility without
good reason.

> >>And if we're requiring Apache2, possibly it might make sense to require
> >>mod_perl2 while we're at it; which would let us target the code at that
> >>(instead of healf-heartedly trying to make it sorta work, sometimes).
> >
> >It does not make much sense to me to depend on something without a clear
> >idea of what benefit that might provide.

Agreed.  CGI is more generic/universal/available.  By all means support
modperl, but not at the expense of CGI.

> Oh, sorry, I'd thought the perceived benefits of mod_perl would be obvious.
>
> Being a persistent environment you'd eliminate a whole mess of per-invocation
> overhead, and you'd have deeper access to the server innards if you need it.

mod_validator of course does that: the main benefit it gains is m12n.

> One example of which — that's related to Apache2, not mod_perl as such — would
> be that we could offload SSI processing to the mod_include output filter
> instead of doing pseudo-SSI internally in our code.

That's an example of m12n.  But it comes for free with Apache 2,
regardless of whether check runs as CGI or modperl.

> Of course, we'd need to measure the effects before committing to that course;
> I've always suspected that our obvious gains from mod_perl would be
> insignificant compared to the fork() and processing of «onsgmls».

I wouldn't be too sure of that, for two reasons.  One is onsgmls, which
is not slow for such a complex parser.  The other is the generic API:
has anyone benchmarked the Perl bindings thereof?

> What I'd initially think was a good list to target is:
>
> * Fedora (Ville is tracking this and I'm developing on it)
>     and Red Hat Enterprise Linux 3 and 4.
> * Debian Stable and Testing(?).

Debian stable?  Isn't that several years behind current software in
all important things?

> [chop]
>
> Anything that should be added to that list? Can anyone fill in the missing
> pieces of that list?

The BSDs?

Anyway, that's the business of packagers, yesno?

-- 
Nick Kew

Received on Tuesday, 7 September 2004 00:15:37 UTC