perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Re: nuking old mod_perls before installing unstable
Date Wed, 23 Mar 2005 05:08:21 GMT
> When I see 'use Apache2', i dont see a version number.  I completely 
> concur with Stas that tieing it to a version number is a bad idea.  But i 
> dont care whether it is Apache2 or ApacheBlue or ApacheNextGen, so long as 
> it is different from mp1 the namespace.  
> mp1 and mp2 are sufficiently different (and incompatible) that, from my 
> usage of them, they should be considered different products and hence have 
> different names.  I find it very misleading and confusing to think of mp2 
> as being version 2 of mod_perl.  They are entirely different animals.  
> Basically I am advocating zero guarantee of compatibility between mp1 and 
> mp2, and the simplicity that it will bring.  As a long time reader, I read 
> post after post trying to tapdance on eggshells to keep mp1 and mp2 
> playing nice together and the developer in me doesnt see a point to it.  

Hear hear. This was one of the key points I was trying to cover during 
my previous New Years ranting.

For any product that exists primarily as an API, you are really 
producing two products.

Firstly, an implementation that achieves some effect.

Secondly, an API that describes how to interact with the product.

The version of the implementation is not the same as the version of the 
API. If Apache2:: can be kept compatible (or "almost" compatible) then 
there is no need to increment the API version, regardless of whether the 
implementation version goes to 2.2 or 2.4 or 3. (OK, 3 could get touchy 
from a conceptual POV, but the PMC has decided to let the mp3 team deal 
with that).

mp2 changes not only the implementation version, but also incompatibly 
breaks the API, giving us a new different product. Of the various ways I 
offered earlier to resolve the situation, the majority of opinions I and 
others have encountered is that if the API is dramatically different, it 
needs a new name. Whether this is Apache2:: or Cherokee:: or 
BlackFoot::, I'm not sure people particularly care.

Many projects currently maintain alternative CGI:: and FastCGI:: and 
Apache:: and MasonX:: web server interfaces (or what have you) to their 
web applications. I don't see that changing the name will do much more 
than mean adding an Apache2:: interface for most of these.

Having looked at the source of some of the Apache:: module that were 
upgraded to handle the two alternative APIs in the same namespace, they 
tended to be heavily bloated in any case.

Separating out the server-API-dependent part out from the rest, and 
making two or three alternative pluggable backend modules can only be a 
good thing. (but that's just my opinion).

Geoff, when I said earlier that the Apache-specific MakeMaker was a bad 
example, perhaps mp2doc would serve as a much better example for my 
question about if we can just remove these now.

Adam K

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message