httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: story posted
Date Thu, 06 Feb 2003 18:44:29 GMT
Aaron Bannert wrote:
> On Thursday, February 6, 2003, at 10:15  AM, Bill Stoddard wrote:
> 
>>> Also, I should point out that something as seemingly simple
>>> as an SSI file that includes multiple php scripts needs the
>>> filter stack.
>>
>>
>> So is that a popular configuration in use with 1.3 today?  If not, 
>> then I hold this up as a trophy illustrating my earlier assertion 
>> regarding overengineered 'solutions' to non existent problems.
> 
> 
> It doesn't really matter if it's in use by 1.3 today. If it's in
> use in 1.3 today then what use would 2.0 be?
> 
> I've seen numerous bug reports stating this simple case. That to me
> validates this as a use case.
> 
> -aaron

It is painfully obvious that the requirement is not important enough to 
the PHP team (or the majority of PHP users) to cause them to hack their 
code to enable it to work effectively as an Apache 2 filter. I honestly 
don't blame them for the decision.  If we care about our users, our 
development time should be spent on the things that have the most 
benefit to our users.  Spending large amounts of time rewriting (and 
destabilizing) code used by 100% of the PHP user base for the sole 
purpose of providing a piddly capability that will only be used by an 
infintesmal fraction of PHP users is not a good investment. IMHO.

On an aside... I bet if you let mod_php be a handler, you can still do 
some pretty interesting things with output filters like mod_include. PHP 
  would own the file descriptor and could be told (via config) to insert 
the SSI filter. Subrequests would be generated for the PHP tags and they 
would be handled by the PHP handler. I don't see that this requirement 
dictates PHP being a filter.

Bill


Mime
View raw message