> * Obsolete OS support:
>> Likewise in the Zend, TSRM, ext/opcache ... sources, there is
>> conditional code dependent on BeOS, __sgi, __osf__, __IRIX__, PI3WEB,
>> GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs
>> that are no longer actively supported.
Removing from the source any OS that PHP no longer supports seems like
a no-brainer. But if the OS is no longer actively supported by its
owner, that isn't the same as not supported by PHP, right? For
example, will the IIS 5.1 docs be removed at XP's end date (4/8/2014),
or some known period after that? And IRIX is still supported by SGI
AFAIK (we have a compute cluster running it, though no PHP there).
I'm not taking a side for or against any one of these. I'm just
wondering what standards dictate when PHP is not longer supported on a
given OS: a separate RFC and vote for each OS is a fine answer, even
though I can't vote! But not having compiled for an OS in a while
shouldn't be reverse-engineered as having voted to remove support,
know what I mean?
> * Obsolete SAPI list:
>> Examples of what I am talking about are SAPIs with no clear evidence
>> of active support (I've listed the last non-bulk change in brackets to
>> give a measure of the level of support):
>> aolserver (2008), caudium (2005), continuity (2004), phttpd (2002),
>> pi3web (2003), roxon (2002), thttpd (2002), tux (2007), webjames
>> (2006)
Not a deeply held objection... but as a long-ago Roxen fan, I have to
question pushing a SAPI for removal based only on the date of the
_SAPI_'s last touch. If the target server also hasn't been updated in
a long time and is on a supported OS, that SAPI-server combo is 99%
sure to still work. And it's perhaps overly strict to say that someone
who is still nursing an old HTTPd can't use the latest PHP features
just because we didn't feel like shipping the bridge anymore.
Unfortunately, getting usage stats for most of those servers is next
to impossible unless someone pipes up and says a certain widely
released app (I'm thinking stuff like server management utilities) may
want to take advantage of later PHPs. There might be some "white
label" webmail packages whose operators don't even remember that
they're based on one of those servers. I do doubt there are more than
a handful of general-purpose public-facing sites using them, though.
-- Sandy