- From: Nick Kew <nick@webthing.com>
- Date: Tue, 7 Sep 2004 01:15:05 +0100 (BST)
- To: Terje Bless <link@pobox.com>
- Cc: QA Dev <public-qa-dev@w3.org>
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