W3C home > Mailing lists > Public > public-qa-dev@w3.org > September 2004

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

From: Terje Bless <link@pobox.com>
Date: Mon, 6 Sep 2004 13:02:55 +0200
To: QA Dev <public-qa-dev@w3.org>
Message-ID: <r02010300-1035-4E63C366FFF411D8878C0030657B83E8@[193.157.66.23]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bjoern Hoehrmann <derhoermi@gmx.net> 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.

Iff that was the case we'd have two obvious options; either fix «check» to be
portable (in terms of hosting server), or to admit that we're Apache-bound and
take advantage of it.

We've got a shining light at the end of the tunnel with m12n that should make
it possible to make specific frontends for specific environments, so having
the current «check» slowly morph into the Apache/mod_perl frontend might make
sense — despite losing the other environments — in the interrim.


But if we're not more Apache-bound that people have had it running under IIS
then we're not that bad off. And as the SOAP code demonstrates we can pull
some god-awfull stunts if we need to to make it work in ways not intended by
the CGI gods. :-)


>>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.

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.
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.

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».


And IMO, targetting mod_perl implies targetting Apache, so if we've discounted
that then this issue is also moot. Ville has done some excellent work in
making «check» support running under mod_perl — I've borked it at some point
during 0.6.7->HEAD, but… :-) — so we can probably pick the low-hanging fruit
that way without limiting ourselves.


>We should try to avoid depending on code that won't work on specific
>mainstream platforms, but I do not think we should officially support
>anything but validator.w3.org/qa-dev.w3.org (in terms of testing,
>commiting to fix bugs in our dependencies to make them work elsewhere,
>etc.) Nice if people do that, but lack of properly tested support on a
>specific platform should not hinder us to release a stable version of
>the validator, the ability to run local installations only affects a
>minority of our users.

Hmmm. I think we agree here, except I would like to go further in facilitating
use on multiple platforms (that doesn't imply officially support, BTW).

I was looking for a list of linux distributions, commercial UN*X variants,
etc.; and what versions of these are currently relevant in terms of deployed
base. The intent being to investigate what minimum versions of various
dependencies they ship to determine what we can safely require.

e.g. commercial UN*X is almost guaranteed to not provide Perl 5.8.x yet, and
I'm betting several Linux distros are shipping 5.6.x or versions <5.8.5, but
Fedora Core — which is what I'm developing on — does ship 5.8.5.

If I were to look solely at what is in front of my nose I'd quickly rely on
Perl 5.8.5 — and we can install that on qa-dev/v.w3.org if needed — which
would make local installations all but impossible.


e.g. Mac OS X is probably deployed in 10.2 and 10.3 versions, and 10.4 is
scheduled for release soon. 10.3 ships with 5.8.1-RC3, but IIRC 10.2 shipped
with Perl 5.6. Given what's happening in Perl-land and the schedule for 10.4,
I'd say it's a good bet that 10.4 will ship with a recent 5.8.x version.

Given that, I'd consider 10.2 to be below the line and require Perl 5.8.

Also, in general, the main Linux distros are shipping 5.8 and ActivePerl is at
5.8. Debian might be a problem due to their long release cycle, and RHEL
(which ships with 5.8.0) for the same reason.


We can get away with replacing «opensp», but replacing Perl is usually out of
the question.


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(?).
* SUSE Desktop and Enterprise. Versions?
* Mandrake Desktop and Server. Versions?
* Gentoo?
* Solaris 8 and 9.
* Mac OS X 10.3 and 10.4.
* Windows XP/2000/2003 (for determining depends, since we don't
    really run there as yet)

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


Perhaps a Wiki page listing the lot of them and the distributed versions of
stuff like Perl and various modules? And whether and what version of OpenSP
they ship?


And to make sure there's no misunderstanding: I'm *not* proposing to support
all these! I'm merely saying these are candidates for input to our
decision-making process in terms of deciding what minimum version of e.g. Perl
to require.

Everything points to Perl 5.8 for WMVS 0.8 — as the fixes that require 5.8
probably won't happen for 0.7 — but I want to make sure I really understand
the impact of making that change. I can live with losing the Eunices and
ancient Debian (iff they don't ship 5.8), but if it were to, say, nuke SUSE,
Mandrake, and Gentoo I'd be a little more worried.

And some of our dependancies (Perl modules) require a C or C++ compiler, most
of them depending on GCC. Odds are good that some modules will require a
specific minimum or maximum version of GCC to build, so what version of GCC
each of these ship is another factor.



Since the Validator — despite our best intent — is still a PITA to install
(for all but Debian and Fedora users), we can live quite happily continuing in
the same way we have in the past. But I would much prefer to have better input
for making these decisions for the future.

- -- 
Everytime I write a rhyme these people thinks its a crime
I tell `em what's on my mind. I guess I'm a CRIMINAL!
I don't gotta say a word I just flip `em the bird and keep goin,
I don't take shit from no one. I'm a CRIMINAL!

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.3

iQA/AwUBQTxD3aPyPrIkdfXsEQKwzACfQtfK+J6KhU+gyI+IRfbuWYXKXCsAoMM1
V+QYYakU53tRRqRM/QJDoGC2
=Ye7B
-----END PGP SIGNATURE-----
Received on Monday, 6 September 2004 11:02:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:44 GMT