Re: Obsolete SAPIs

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