Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70522 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10309 invoked from network); 7 Dec 2013 20:16:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Dec 2013 20:16:48 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:54705] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 33/11-01020-D2283A25 for ; Sat, 07 Dec 2013 15:16:47 -0500 Received: from bad.dop.co ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id SGX26839 for ; Sat, 07 Dec 2013 12:16:39 -0800 Date: Sat, 7 Dec 2013 15:16:33 -0500 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <823619687.20131207151633@cypressintegrated.com> To: Terry Ellison In-Reply-To: <52A1E615.40300@gmail.com> References: <1386315591.31655.16.camel@smugmug> <52A1E615.40300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Obsolete SAPIs From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > * 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