You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2005/01/01 04:52:23 UTC
[mp2] taking a step back?
As probably with most of you, I'm getting worried with the
tone of the discussion on the mp2 namespace problem, and the
directions it's heading - getting locked out of CPAN, etc.
And, rightly or wrongly, getting a a sizeable fraction of
the Perl community upset on the eve of the official mp2
release can't be a good thing ... Also, though, like Joe
raised, it's upsetting that a good portion of the flames are
directed at Stas, who has put so much into mp2, both inside
and outside of the actual code.
The fundamental issue of using the Apache::* namespace for
modules both in mp1 and mp2 sounds like an unresolvable one.
On the one hand, at the level of a script or handler,
Apache::Request (for example) in mp1 has a lot of the same
interface as Apache::Request of mp2. However,
Apache::Request itself built under mp1 can't be used under
mp2, and vice-versa. A lot of this worry seems to be
directed at potentially bad recommendations of the
CPAN/CPANPLUS shell - this could be addressed by PAUSE
supporting generations in the future (near or far), or it
may have to wait until perl6, but from the sounds of things,
nothing along these lines will be probably be done in the
near term (ie, the next few months); even if Autrijus comes
up with a workable proposal in the next month, implementing
this, on PAUSE or elsewhere, would take some more time
(especially given Andreas', and others', views on this), and
then it would be longer to get workable clients out there.
Although this may not be the best time to raise this, the
strong opinions being expressed, plus the shortness of time
on the part of the many of us, perhaps we could look at what
would be involved to move the modules in the mp2 core so as
not to conflict with mp1. If I counted right, there's not
that many:
Apache::Log
Apache::PerlSections
Apache::Resource
Apache::SizeLimit
Apache::Status
Apache::URI
Apache::Util
Putting aside for the moment the relationship of these to
their mp1 counterparts, it shouldn't be too hard to come up
with alternate, descriptive names, either in an Apache2::*
or ModPerl::* namespace, or perhaps just something different
under Apache:: (eg, Apache::Utility).
The question of mod_perl.pm itself is different. In the mp2
distribution, in a sense this is used to "brand" the whole
package - give it a version, and a pod NAME and description.
Although I see Stas' argument about not having a mod_perl.pm
and mod_perl2.pm in the same package, what about just
renaming mod_perl.pm to mod_perl2.pm? And in keeping with
the use of mod_perl.pm to give an abstract that
search.cpan.org can use for the mod_perl distribution,
renaming the mp2 distribution itself to mod_perl2. If one
sees the use of mod_perl.pm as just representing the
package, then calling it mod_perl2.pm may not be too
unnatural, given that Apache1 modules are fundamentally
different from Apache2 modules.
There's at least two questions that immediately arise with
this. The first - how much physical work would it be to do
this renaming? Quite a bit, I imagine, but a finite amount -
I'd be willing to set aside some time in the immediate
future to work on this. The bigger issue is how such a
change would affect existing 3rd party code that currently
uses mp2? This may cause quite a bit of headaches -
"legally" I guess one is free to do this, since mp2 isn't
officially released yet, but one doesn't want to alientate
existing users. I fear, though, that if mp2 gets
marginalized, even in the short term, by a (sizeable)
segment of the general Perl community, this would be a
bigger long-term problem for early adopters. This might not
happen, of course, but is it worth the gamble? Perhaps, as a
stop-gap measure, one could make up a compatibility layer,
similar to Apache::compat, that would assist in the
change-over.
The question of Apache2.pm then also arises, as,
theoretically, if such changes were made, Apache2 wouldn't
be needed. A couple of people have mentioned that they like
Apache2 just as a way of separating mp1 stuff from mp2 -
given this, we could keep Apache2 in there, but make it
optional (and, perhaps, recommended in the case of an
existing mp1 install). That would make the transition
easier, but also satisfy the concerns raised about mp2
*necessarily* breaking existing tools.
As Stas has emphasized, doing this to the core modules
doesn't address the broader issue to 3rd party modules. It's
probably reasonable to assume though that these developers
would understand why this was done, given the strong
opposition and the desire to have mp2 supported as much as
possible in the standard Perl environment.
Again, I raise the above not necessarily because it's the
best solution within the mp2 environment, but because of the
pretty strong opinions expressed on the other side. I'm
also, frankly, worried about the wider implications and
effects raised about this namespace problem outside of mp2
if we don't do this, and as Adam said, getting into a cycle
of outwardly spirallying workarounds to solve yet other
problems we haven't anticipated. It may be better, from the
point of view of keeping peace within the community, making
these changes now, and wait until "official" support for
generations is in place (which seems to be acknowledged as a
real need, both for mp2 and others), either in perl5 or,
perhaps, perl6.
And Happy New Year!
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Adam Kennedy <ad...@phase-n.com> writes:
[...]
> What is causing the biggest issue for me, as someone who as a rule
> _never_ gets involved in these kinds of things in public, is that he
> is willing to immediately and completely discount the opinions of
> everyone else, whether or not they are trying to have a reasonable
> discussion or not.
>
> And what is SCARING the HELL out of me is that he is not even willing
> to wait for a few days or weeks to have a proper discussion with those
> of us who _are_ reasonable most of the time.
Being driven by fear is something we should try hard to avoid.
There is no reason whatsoever to be afraid of seeing more
candidates, while also discussing the current issues that have
arisen during the process. It is clear that the Apache::Resource
indexing problem is currently our bug, and hopefully the next
candidate will incorporate a fix for it. But we're just aiming
for "better than the last one, please test it" right now.
As to the rest of your email... I am simply unable to read anything
beyond the above paragraph. I can appreciate that you're trying hard to
be helpful, but singling out any particular developer on an ASF project
is *never* the right thing to do. The role of a release manager is a
damned tricky role to play, and we won't be making it any more difficult
by tossing tomatoes at the person volunteering.
It's the collective consciousness of this mailing list that you
need to be addressing, not any particular person. Here is a
webpage that I hope will help you with the culture clash you must
be experiencing:
http://www.apache.org/foundation/how-it-works.html
None of the p5p/usenet/irc standard operating procedures apply
here. Had you had the time to lurk, there's no doubt you'd
have picked up on the key differences which prevent folks like
me from reading emails like yours. But I can appreciate that
you've been thrust into a difficult situation.
I hope this helps.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Adam Kennedy <ad...@phase-n.com>.
> You really should get off Stas here. He said clearly: do your homework.
> We discussed this issue (not the "whether to do it", but the "how") here
> not so long ago[1] ; nobody cared to comment and we failed to get to
> anything useful (short summary: either trading MP_INST_APACHE2 hack for
> a big mess or abandoning Apache::compat).
>
> Stop bitching, show the code.
I'd be more than happy to do so, assuming that I can buy myself enough
time to actually take a look beyond more than just the symptoms, and
have a look at the mod_perl internals properly.
And as long as I and a few others can have some time to examine the
problem properly, I'm more than happy to act in a totally reasonable manner.
I also hope you will appreciate you are going into this release during a
holiday period when some of us have less than ideal access to systems
with which to do a proper analysis and test solutions.
And I'm not used to being summarily dismissed on a decision which is
going to be largely irrevocable, and for which I have demonstrated
potential fixes for the problems for which I haven't seen any
counter-proofs.
A simple assurance from the PMC that you won't release before I've had a
chance to get back to my office and address your problems properly.
I wouldn't be acting to extreme if I didn't feel like I'm racing the
clock on this.
As for showing the code, here is a start.
Assuming you use Apache2::, as a fairly trivial demo I've created
Apache2::GTopLimit 0.01, it took about 20 minutes to move it over, the
new one uses a standard Module::Build script instead of the huge
workaroundy thing that existed.
I'll throw it up as soon as I get back to the office next Monday, and
you can check it out.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Radoslaw Zielinski <ra...@karnet.pl>.
Adam Kennedy <ad...@phase-n.com> [02-01-2005 07:32]:
> Randy Kobes wrote:
>> As probably with most of you, I'm getting worried with the
>> tone of the discussion on the mp2 namespace problem, and the
[...]
> Stas, as the leader (or at least lead developer) of the project, is
[...]
> What is causing the biggest issue for me, as someone who as a rule
> _never_ gets involved in these kinds of things in public, is that he is
> willing to immediately and completely discount the opinions of everyone
> else, whether or not they are trying to have a reasonable discussion or not.
> And what is SCARING the HELL out of me is that he is not even willing to
> wait for a few days or weeks to have a proper discussion with those of
> us who _are_ reasonable most of the time.
[...]
You really should get off Stas here. He said clearly: do your homework.
We discussed this issue (not the "whether to do it", but the "how") here
not so long ago[1] ; nobody cared to comment and we failed to get to
anything useful (short summary: either trading MP_INST_APACHE2 hack for
a big mess or abandoning Apache::compat).
Stop bitching, show the code.
[1] Subject: [apr] dropping Apache2/ subdir for APR::*, November 2004.
--
Radosław Zieliński <ra...@karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
Re: [mp2] taking a step back?
Posted by Stas Bekman <st...@stason.org>.
Adam Kennedy wrote:
> To this list:
>
> I've been advised that in a situation like this it isn't wise to keep
> emails off the list, so I'm bringing a private conversation back into
> the list, since it has gone a lot further than I had expected.
Adam, what you just did is simple unacceptible. You took the private
conversation and brought it into a public w/o asking my permission for
doing that. This is just f**king rude.
So long and thanks for all the fish.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Adam Kennedy <ad...@phase-n.com>.
To this list:
I've been advised that in a situation like this it isn't wise to keep
emails off the list, so I'm bringing a private conversation back into
the list, since it has gone a lot further than I had expected.
Stas Bekman wrote:
>>> This is just a software. This is not real life. So making enemies
>>> based on software disagreement is at least foolish.
>>
>>
>> Not real life? I have a company that is currently trying to convince
>> customers that mod_perl2 is going to be a good enterprise platform,
>> and that perl and thus my company build the best web applications.
>
>
> But mp2 doesn't have a problem. If your customers choose mp2 it'll just
> work. The whole issue is about edge cases, which I fail to see how they
> possibly affect your business.
But that is demonstratably wrong. Not having access to any of the perl
standard perl infrastructure is a problem. I have to tell them.
I've built this system, but if you ever need to fix something, don't use
any of the standard tools because mod_perl2 is incompatible.
>> I don't know about you, but I consider my career and my business real
>> life.
>
>
> I didn't mean that. I meant the API choice. If you tell me that the API
> naming will mean death or life for your business, I'm sorry, I can't
> offer you much help here.
It's hardly life and death, and the API choice isn't the problem. If you
could make the API choice without requiring so much incompatibility and
damage, this wouldn't be a problem.
>> If you don't accept that a problem is even a problem, and it appears
>> to me from your responses that you don't understand why it is a
>> problem, then I shouldn't try to convince you?
>
>
> What's wrong with having a different opinion from yours? As it's seen
> from my tower there is no problem. There are a few inconveniences, but a
> problem?
Then maybe you need to come down from your tower for a little while.
These are not small inconveniences, these are big inconveniences. And
while YOU may think them small, I assure you that other people do not.
And these same people can suggest solutions to the problem to you, and
are willing to help, and you refuse to even wait to let them help.
>>> Now again, don't get offended, but you need to wear my shoes to be
>>> able to judge my position. I know what's the best for modperl users,
>>> even though it might be against your position. And that's fine. You
>>> have to admit that you are in no position to judge our decisions,
>>> since I don't remember you contributing a single bit to the modperl
>>> project.
>>
>>
>> Well, for starters nobody can work on _every_ project. And every time
>> I've asked people how mod_perl2 was going, I had been assured it was
>> being taken care of...
>
>
> How is that our fault? The current scheme was out there for 3+ years!
> The fact that you've relied on someone else to do the assurance, is not
> our problem. You are too late into the game. Release Candidates are out,
> people already run their businesses using the current API, since RCs
> indicate no API changes (well as little as possible). Why do you allow
> yourself to make a decision on behalf of these users, and force them to
> rewrite their code, because you aren't happy about it? Have you
> considered that?
Yes I have. I've talked to some of these people who have indicated that
they don't mind.
These early adopters go into this knowing things might change, and they
represent around 15% of your total user base. You owe your ENTIRE
userbase to produce a better designed and better integrated system more
than you owe the early adopters there will be no change.
In any case, I'm not suggesting wholesale changes. I don't suggest any
changes in the actual API itself or the underlying implementation at
all, just that you don't clash with the old one.
For the most part, it would just involve s/Apache::/Apache2::/
And until a production release is out, people understand that there
might be change. While it may be my fault for waiting as long as I have,
that is no excuse for not dealing with problems once they have been
presented.
>>> On the other hand I've spent 6 years of my life, doing modperl day
>>> and night. I'm not offering pressing charges against your projects.
>>> And I think you should stop doing that for ours.
>>
>>
>>
>> It's only "pressing" because it would appear that I'm not being given
>> enough time to do some better analysis and provide some proper
>> solutions. I'm seeing huge problems and being thrown into a situation
>> at extremely short notice to try and provide solutions to problems I'm
>> currently absolutely confident I can fix, while working against the
>> clock from a laptop in my care while I'm supposedly on holidays.
>>
>> And some of these problems can't be fixed once you release properly.
>
> As explained above, unfortunately, you've missed the train. If you'd
> have come up earlier everything may would have been different.
Until you have done a production release you can make any decision you like.
>>> You need to earn a voice in a community where you try to enforce
>>> changes. You can certainly offer things, and we listen to suggestions
>>> just like from any other user. But you must not demand things if your
>>> suggestions aren't accepted.
>>
>>
>>
>> All I demand is time.
>
>
> Sorry, but we have no time. Let me explain something. modperl is being
> developed on almost 0 resources. Most of developers are very busy and
> have no time to develop or support the product. I was the lucky one to
> have windows of full time work on modperl, but in 2 weeks I go back to
> school and there will be almost 0 resources to push for a release, deal
> with bugs, questions and writing docs. Now you understand why I can't
> wait. It has been dragging for too long and it must come out now. Any
> other delay is playing against us. Many users have expressed this as a
> problem, since they can't even start moving to mp2 before an official
> 2.0.0 is released.
>
> As you run a business you know what a deadline is. We had a deadline set
> on dec 2004, we have missed the deadline already. So if someone did
> something wrong, it'll be fixed in the next iteration. But the product
> must ship now.
How many times must I say that this problem is something you CANNOT fix
in the next iteration. The two core problems are something you are going
to have to live with indefinitely.
>> I'm afraid that I can't stas. But I'd rather work with you than
>> against you.
>
>
> Me too, but the circumstances aren't right to do any change now.
People have already volunteered to help with any changes.
>>> BTW, whereabouts in AU are you?
>>>
>>
>> I live in a place called Lismore, in northern NSW. I'm currently in
>> Newcastle in a Internet cafe with zero access to my normal development
>> gear with which to provide you actual solutions.
>
>
> I haven't been to NSW, I've spent 6 month in Melbourne 1.5 years ago and
> I loved it. I'm planning to come back one day.
>
>> Again, give me the time to deal with this properly, and I'd be more
>> than happy to back off from my current position.
>>
>> I'm not an unreasonable person.
>
>
> I'm not saying you are, but I hope now you understand my attitude.
I do. It's obvious that you feel you are irrevocably committed to this
release, and that nobody else has the chance to change this.
On one hand I'm being told that it's the mod_perl community that
controls this stuff, and on the other I'm being told by you something
different.
If others in the mod_perl community want to at least pause to check
whether this can be solved, what am I supposed to believe...
>> Indeed, I'm probably more reasonable than most of the people that have
>> been talking to you until now, like Randal.
>
>
> :)
>
>> But I _hate_ working against the clock.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Adam Kennedy <ad...@phase-n.com>.
Randy Kobes wrote:
> As probably with most of you, I'm getting worried with the
> tone of the discussion on the mp2 namespace problem, and the
> directions it's heading - getting locked out of CPAN, etc.
> And, rightly or wrongly, getting a a sizeable fraction of
> the Perl community upset on the eve of the official mp2
> release can't be a good thing ... Also, though, like Joe
> raised, it's upsetting that a good portion of the flames are
> directed at Stas, who has put so much into mp2, both inside
> and outside of the actual code.
Stas, as the leader (or at least lead developer) of the project, is
naturally going to attrack some level of flame, especially from those
that are themselves fairly hot, like Randal. (and I know he won't mind
me calling him a firebrand) :) I've been flamed by him for controvertial
ideas a few times myself.
What is causing the biggest issue for me, as someone who as a rule
_never_ gets involved in these kinds of things in public, is that he is
willing to immediately and completely discount the opinions of everyone
else, whether or not they are trying to have a reasonable discussion or not.
And what is SCARING the HELL out of me is that he is not even willing to
wait for a few days or weeks to have a proper discussion with those of
us who _are_ reasonable most of the time.
(BTW, I apologise for my previous outburst, but I to leave my New Years
Eve party early and go back to work still somewhat drunk in order to
deal with this before my long drive yesterday)
He seems to have fully committed to the release, no matter what problems
are found or what anyone, including some of his own development team, says.
While there are around 8-10 items I would personally consider to be a
major concern, there are 2 of these that are absolutely fundamental
problems that you can't just release and find workarounds for later.
These problems are
1) Perl does not allow and cannot support multiple API versions in the
same module name to be considered "current". You MUST choose between
end-of-life'ing the old one immediately, or use a different name.
mod_perl2 appears to refuse to pick either of these.
2) API overloading (parellel module trees) means that you lose support
for the entire of the Perl public infrastructure. This will cause major
problem for ALL of your userbase, who are also one of the three main
groups of OUR userbase.
These two are bad things. Bad bad bad bad bad! On these two problems I
can safely say that the entire of the perl developer community agrees
with this.
The rest of the problems are largely symptomatic and I'm happy to ignore
them if we can resolve these two. Most will vanish if we solve these2
any ANY of the 5 or 6 possible ways I think it can be done.
You cannot just bluster though these objections, or assume they will go
away, as stas would appear to be doing.
Shutting your eyes and singing "la la la la", or attacking the
messengers will not help you get past these problems.
Whether it is bullheadedness, or a cognative dissonance given how close
mod_perl2 is to release, I can't say.
But this is what is causing stas to get most of the flames here,
compounded by his position as the figurehead for mod_perl 2.0.
> The fundamental issue of using the Apache::* namespace for
> modules both in mp1 and mp2 sounds like an unresolvable one.
> On the one hand, at the level of a script or handler,
> Apache::Request (for example) in mp1 has a lot of the same
> interface as Apache::Request of mp2. However,
> Apache::Request itself built under mp1 can't be used under
> mp2, and vice-versa. A lot of this worry seems to be
> directed at potentially bad recommendations of the
> CPAN/CPANPLUS shell - this could be addressed by PAUSE
> supporting generations in the future (near or far), or it
> may have to wait until perl6, but from the sounds of things,
Perl 6 may indeed be able to solve some of these problems in a different
way.
> nothing along these lines will be probably be done in the
> near term (ie, the next few months); even if Autrijus comes
> up with a workable proposal in the next month, implementing
> this, on PAUSE or elsewhere, would take some more time
> (especially given Andreas', and others', views on this), and
> then it would be longer to get workable clients out there.
The perl "standard timeframe" for moving to new systems like CPANPLUS or
Module::Build or PPI (once I finish it) is around 2 or 3 years, with at
LEAST 5, preferably 10 years before we stop supporting it altogether.
Ideally, we try to maintain back-compatibility forever. Perl 6 will
still support much perl 5.004 code.
As a point of reference, the current "minimum perl version support in
CPAN" debate is over whether it is acceptable yet to have 5.6 as a
standard minimum version, and that has been out for AGES. For the
record, I'm on the side that says authors should still support 5.005
unless you have no other choice.
All of Perl culture tried to be back-compatible indefinately, if
possible, and to only break it for good reasons. And when we break, to
break completely.
> Although this may not be the best time to raise this, the
> strong opinions being expressed, plus the shortness of time
> on the part of the many of us, perhaps we could look at what
> would be involved to move the modules in the mp2 core so as
> not to conflict with mp1. If I counted right, there's not
> that many:
>
> Apache::Log
> Apache::PerlSections
> Apache::Resource
> Apache::SizeLimit
> Apache::Status
> Apache::URI
> Apache::Util
>
> Putting aside for the moment the relationship of these to
> their mp1 counterparts, it shouldn't be too hard to come up
> with alternate, descriptive names, either in an Apache2::*
> or ModPerl::* namespace, or perhaps just something different
> under Apache:: (eg, Apache::Utility).
>
> The question of mod_perl.pm itself is different. In the mp2
> distribution, in a sense this is used to "brand" the whole
> package - give it a version, and a pod NAME and description.
> Although I see Stas' argument about not having a mod_perl.pm
> and mod_perl2.pm in the same package, what about just
> renaming mod_perl.pm to mod_perl2.pm? And in keeping with
> the use of mod_perl.pm to give an abstract that
> search.cpan.org can use for the mod_perl distribution,
> renaming the mp2 distribution itself to mod_perl2. If one
> sees the use of mod_perl.pm as just representing the
> package, then calling it mod_perl2.pm may not be too
> unnatural, given that Apache1 modules are fundamentally
> different from Apache2 modules.
Although not a universal thing, and not really definitavely provable,
the preference does seem to be that we should use Apache2. That seems to
be the "view of the common man" as far as I can tell.
It makes support simple and is completely logical from a user
perspective. Apache treats it as a different product., distro package
names say apache2, why shouldn't perl modules be Apache2::. It makes
complete sense to go looking for an Apache2:: version of any current
package you are using, like say Apache::GTopLimit, when moving to the
new server.
If you can't find it, you might look at the old one to see if it is
compatible, but it's a simple common sense rule that everyone would
expect as soon as they had seen it once. It's a SIMPLE rule, and doesn't
require 40 paragraphs of documented workarounds to follow.
> There's at least two questions that immediately arise with
> this. The first - how much physical work would it be to do
> this renaming? Quite a bit, I imagine, but a finite amount -
> I'd be willing to set aside some time in the immediate
> future to work on this. The bigger issue is how such a
> change would affect existing 3rd party code that currently
> uses mp2? This may cause quite a bit of headaches -
> "legally" I guess one is free to do this, since mp2 isn't
> officially released yet, but one doesn't want to alientate
> existing users.
I actually suspect (although obviously I can't prove it) that it would
be far less than the work the early adopters have already done. A simple
s/Apache::/Apache2::/ would get you a significant percentage of the way
there, if we could agree on a recomendation to move to Apache2::.
And most early adopters I've talked to don't seem to mind if it means
they are allowed to use search.cpan.org again, and perldoc, and man, etc
etc...
And frankly, early adopters accept going in to their efforts that
mod_perl2 is NOT a stable product, and changes might happen at some point.
That's why only 1/6 of mod_perl servers as using the new one, and the
5/6ths who don't want to risk it haven't started porting at all yet.
I'm more concerned about hurting the main body of users, the early
adopters are smarter and far more capable of handling it than the
conservative users.
> I fear, though, that if mp2 gets
> marginalized, even in the short term, by a (sizeable)
> segment of the general Perl community, this would be a
> bigger long-term problem for early adopters. This might not
> happen, of course, but is it worth the gamble? Perhaps, as a
> stop-gap measure, one could make up a compatibility layer,
> similar to Apache::compat, that would assist in the
> change-over.
I think we can actually do more than this!
Apache::compat works already, yes?
So if mod_perl2 API is in Apache2::, and Apache::compat is altered to
let Apache:: work as normal on mod_perl2, it means that mod_perl1
applications and mod_perl2 applications can work alongside completely
cleanly WITHIN THE SAME Apache 2 server.
This would seem to give us (although admittedly, at this point, with
some amount of work) COMPLETE upwards compatibility!
Think of the level of adoption of Apache 2 this would drive if most
people don't have to change their code immediately, if they are willing
to accept a (small?) speed penalty. This lack of Apache 2 adoption is a
huge concern at the present yet?
I can't prove this is possible, but I'm sure someone from the mod_perl
development team could demonstrate if this is possible, or impossible.
In fact, given what would seem to be the possibility to massively Apache
2 uptake, compared to the current scheme restricting mod_perl2 uptake,
I'm going to CC the Apache Foundation committee in from here on in if it
looks like the release is going ahead anyway and I have to keep
escalating my response, past just talking.
> The question of Apache2.pm then also arises, as,
> theoretically, if such changes were made, Apache2 wouldn't
> be needed.
And we also wouldn't need mp2doc, mp2cpan, mp2pod2man, the special
MakeMaker implementation, the version of only.pm implemented inside
Apache2, and all sorts of other things you could just delete outright.
> A couple of people have mentioned that they like
> Apache2 just as a way of separating mp1 stuff from mp2 -
> given this, we could keep Apache2 in there, but make it
> optional (and, perhaps, recommended in the case of an
> existing mp1 install). That would make the transition
> easier, but also satisfy the concerns raised about mp2
> *necessarily* breaking existing tools.
>
> As Stas has emphasized, doing this to the core modules
> doesn't address the broader issue to 3rd party modules. It's
> probably reasonable to assume though that these developers
> would understand why this was done, given the strong
> opposition and the desire to have mp2 supported as much as
> possible in the standard Perl environment.
Indeed, one of my other 6 concerns is that regardless of any damage you
cause yourselves, some of the decisions you have made for mod_perl2
arn't constrained to just you, they force many of the authors of other
Apache:: down the same path, and lock THEM out of the standard Perl
environment (both system and the internet tools) as well.
I checked some numbers on this this morning. There are currently 318
perl distributions in or related to Apache:: that build on top of core
mod_perl. If their authors (which includes me for PPI::Format::Apache)
follow the recommended and DOCUMENTED method for upgrading to mod_perl 2
and use this "use Apache2;" mechanism without also simulataneously
supporting mod_perl 1 in the same package, THEY will have to be locked
out of the standard Perl environment as well. This is going to be very
confusing and piss them off a lot.
There is currently (I think) one package locked out. The uninstallable
nightmare that is Meta::.
We really really really don't have to have to lock out 300 or so packages.
We end up with the effect of confusing and annoying the very developers
you are trying to "not confuse" by sticking with Apache::
> Again, I raise the above not necessarily because it's the
> best solution within the mp2 environment, but because of the
> pretty strong opinions expressed on the other side. I'm
> also, frankly, worried about the wider implications and
> effects raised about this namespace problem outside of mp2
> if we don't do this, and as Adam said, getting into a cycle
> of outwardly spirallying workarounds to solve yet other
> problems we haven't anticipated. It may be better, from the
> point of view of keeping peace within the community, making
> these changes now, and wait until "official" support for
> generations is in place (which seems to be acknowledged as a
> real need, both for mp2 and others), either in perl5 or,
> perhaps, perl6.
You are right about the need.
Support for SOMETHING like generations, at least to prevent ever having
another situation like the nightmarish GD changeover will almost
definately be created at some point. Possibly even for perl 5. This is
the shiny bauble that has caught Autrijus' eye, so it may well happen.
That is, solving "radically different implementation of the _same_ API,
that you can't just upgrade to automatically".
The support for changing an API without making the old one immediately
unsupported is far worse, and may well not get solved, even in Perl 6
(although given Damian is on the case, I wouldn't put it past him).
You need to decide if you want to immediately abandon support for
mod_perl 1 when you release mod_perl 2. (Frankly, I think this is almost
a rhetorical question).
And finally Randy, thank you for you and Joe staying calm during this,
it makes my life a lot easier. Between myself, Autrijus, Andreas,
Randal, and Schwern, (and others) I'm certain we can work together on
this and provide advice that can help mod_perl2 avoid the problems it
currently has, and maybe make it even better.
(Now I have to go write a response to Stas' rather dismissive and
agressive email, and I'm afraid I'm need to going to have to lay out in
no uncertain terms what the worst case scenarios are going to be if this
goes ahead and I have to escalate to the next stage. I apologise in
advance) :(
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by David Wheeler <da...@kineticode.com>.
On Jan 2, 2005, at 3:26 PM, Randy Kobes wrote:
> The possible effect of making
> these more difficult and/or confusing to an average user is
> something, I think, we should consider in deciding on the
> namespace problem.
And that's the rub, I think. I am in complete agreement with Randy
here. As we have no control over those other tools, but we do have
control over mod_perl, it is at least worth *considering* the case made
by an overwhelming representation of the Perl community. It cannot be
dismissed lightly, and, speaking as the owner of a business that relies
on mod_perl, I would hope that we would do everything we can to avoid
releasing mp2 to a cacophony of boos. It will be very bad for mod_perl.
I agree that it would be worthwhile for Perl to have a way of managing
versions as part of module names (as is planned for Perl 6), but if
it's not going to happen for Perl 5, we need to work around it in a way
that will cause the least pain and outcry from the community of users.
Regards,
David
Re: [mp2] taking a step back?
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 1 Jan 2005, Stas Bekman wrote:
[ ... ]
> The other side doesn't understand the problem and you can
> safely ignore them. They are perfectly logical and correct
> to say the things regarding the perl modules they are used
> to. But they don't understand that mod_perl is 10 times
> more complex and different from what they are used to deal
> with, no matter how many hundreds of CPAN modules they
> have released so far.
I'll be brief, as it's probably a good time for reflection,
but the fact that mod_perl is complex is perhaps a good
reason for us to consider the wider implications, to some
degree. Although it's well written, has great user support,
and there's a growing document set (all for which Stas
deserves much of the credit), one of the appeals of mod_perl
is the numerous other Perl resources and support available
(CPAN, *.perl.org sites, etc., including probably a number
of private, in-house tools). The possible effect of making
these more difficult and/or confusing to an average user is
something, I think, we should consider in deciding on the
namespace problem.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by David Wheeler <da...@kineticode.com>.
On Jan 1, 2005, at 8:24 AM, Stas Bekman wrote:
> I say let it go, this is a futile battle, it's useless trying to spend
> any more time to convince that other side that they dig in the wrong
> place. The amount of time people have spent so far trying to convince
> us that we are wrong, could have been used to already implement the
> required changes in PAUSE and CPAN. But no, people prefer to talk...
Since it seems unlikely that this will happen anytime soon, and since
we have no control over CPAN.pm, PAUSE, search.cpan.org, or CPANPLUS,
perhaps we should focus on what we *do* have control over to try to
come up with a solution that will *at least* put an end to the debate.
To my mind, that means one of two things:
1. Move mp2 to a different namespace.
2. Or drop support for mp1 upon the release of mp2.
Given that mp's numbers have been declining, mp2 does need to make a
splash when it is released. But I don't think that all the negative
stuff is the right kind of splash to ensure success.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Randy Kobes wrote:
> [...]
>> Although this may not be the best time to raise this, the
>> strong opinions being expressed, plus the shortness of time
>> on the part of the many of us, perhaps we could look at what
>> would be involved to move the modules in the mp2 core so as
>> not to conflict with mp1. If I counted right, there's not
>> that many:
>> Apache::Log
>> Apache::PerlSections
>> Apache::Resource
>> Apache::SizeLimit
>> Apache::Status
>> Apache::URI
>> Apache::Util
>> Putting aside for the moment the relationship of these to
>> their mp1 counterparts, it shouldn't be too hard to come up
>> with alternate, descriptive names, either in an Apache2::*
>
> -1 to embedding numbers in API
Agreed in principle; however my reasons are centered
around not overburdening the porting efforts of others.
But when people start asking us to do this, and they've
given carefully explained reasons why we should consider
it, I'm not nearly as steadfast about it anymore. I really
like Randy's suggestion to take a moment, and discuss some of
the things Doug first set out to achieve with mp2, and how
well we've been able to follow though with his original plan.
And just as importantly, where this will lead to in the future.
Because I honestly don't see the innate value in having
an architecture-independent Apache:: namespace, when the
mod_perl developers really have no way of controlling what
the httpd developers decide to do with their core data
structures.
Also, it isn't necessarily the case that we also version
APR::, ModPerl::, and friends just because we tag a 2
onto Apache and mod_perl. So let's not lump them all together
just because they're distributed in the same tarball.
As always we try to do what's in the best interests of
our community, and I think having an open discussion
about the Apache:: namespace, from a broad perspective,
is the right thing for us to do.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by K Tensmeyer <ke...@verizon.net>.
On Saturday 01 January 2005 10:24 am, Stas Bekman wrote:
> Randy Kobes wrote:
> [...]
> > Putting aside for the moment the relationship of these to
> > their mp1 counterparts, it shouldn't be too hard to come up
> > with alternate, descriptive names, either in an Apache2::*
>
> -1 to embedding numbers in API
>
> > or ModPerl::* namespace, or perhaps just something different
> > under Apache:: (eg, Apache::Utility).
>
> That's wrong, Randy. What you gonna do when mp2.2 is released, which may
> happen any moment, now that Apache 2.2 is getting ready for its release.
> Rename those again? And again for 2.4? ...
a valid issue.
While a reasonable solution can be found, the preferable methods will be the
ones that seem intuitively obvious, and will work "out of the box" for most
people.
> I can see s/Apache/ModPerl/ for:
>
> Apache::PerlSections
> Apache::Resource
> Apache::SizeLimit
> Apache::Status
>
> since those aren't Apache API really, so they could be moved like Registry
> modules did. Apache::Reload is another one.
>
> These are Aapache API:
>
> Apache::URI
> Apache::Util
> Apache::Log
>
> and can't be moved to ModPerl::.
and we have assumptions as to functionality. ( they should have similary
functions to Apache 1.3.x related modules
>
> > The question of mod_perl.pm itself is different. In the mp2
> > distribution, in a sense this is used to "brand" the whole
> > package - give it a version, and a pod NAME and description.
> > Although I see Stas' argument about not having a mod_perl.pm
> > and mod_perl2.pm in the same package, what about just
> > renaming mod_perl.pm to mod_perl2.pm? And in keeping with
> > the use of mod_perl.pm to give an abstract that
> > search.cpan.org can use for the mod_perl distribution,
> > renaming the mp2 distribution itself to mod_perl2. If one
> > sees the use of mod_perl.pm as just representing the
> > package, then calling it mod_perl2.pm may not be too
> > unnatural, given that Apache1 modules are fundamentally
> > different from Apache2 modules.
>
> -1
yep..
>
> mp2.2 will have mod_perl2_2.pm?
>
> Don't forget that you will need to rename APR.pm as well
this is getting more and more complicated.
the two major side issues are
1) running multiple instances/versions of modperl
2) finding the "right" modules in CPAN to work with the targeted
software.
thanks to the ongoing discussions I understand a little more of the
issues w/regards to CPAN/Pause, but I don't see any quick solution.
One of the common tools/methods used in testing software on the user end
(not the modperl side itself) is to map different configurtion options based
on a logical path. so http://mysite.block.org/config1/applicationA and
http://mysite.block.org/config3/applicationA can refere to the same file but
with different configuration parameters and specified in the httpd.conf file.
While it won't work were API's have changed, it would be 'nice' if similar
approaches could work with mp1, mp2 and mp2.2.X without changing the perl
modules (or scripts). Which leaves only the <Perl> </Perl> segments for
making the specifications. Would it make sense to have some thing which
effects the local @INC (and have it determine which support modules got
loaded?)
Is there a functional modperl equivalent for Perl "require 5.6.1;" ?
so that a reference to APR.pm could be set to the 1.99.X version or the
2.1.X version and have it find the right piece of the pie.
I guess I don't understand enough of the dependency resolution magic to see a
simple solution here.
<hmmm>
about the only part of Schwartz's diatribe that resonated with me is the
assumption that most of the masses testing MP2 would assume that it would be
a drop in replacement for MP1 and would be a simple upgrade.
making it clear to people that it requires major changes to implement and
does not simply replace mp1 as apart of the basic communication will remove a
lot of the silly stuff that would otherwise overwhelm basic bug reporting.
</hmmm>
>
> The other side doesn't understand the problem and you can safely ignore
> them. They are perfectly logical and correct to say the things regarding
> the perl modules they are used to. But they don't understand that mod_perl
> is 10 times more complex and different from what they are used to deal
> with, no matter how many hundreds of CPAN modules they have released so
> far.
>
> I say let it go, this is a futile battle, it's useless trying to spend any
> more time to convince that other side that they dig in the wrong place.
> The amount of time people have spent so far trying to convince us that we
> are wrong, could have been used to already implement the required changes
> in PAUSE and CPAN. But no, people prefer to talk...
<agreed> but, getting people to agree before code get's engraven will save
redoing bad changes several times. I doubt if anyone will stand up and fix
the PAUSE/CPAN issue, because it won't be their ox that is being gored.
(which is usually why people are willing to change code other than their
own.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by David Wheeler <da...@kineticode.com>.
On Jan 2, 2005, at 12:19 PM, Stas Bekman wrote:
>> Those of us who use Apache apps would have to do something like this:
>> eval "use Apache2";
>> use Apache if $@;
>
> What does it mean? You never need to touch Apache2.pm in your mp2
> application. It's not part of the API and you should not use it.
You misunderstand me. I was simply saying that if mp2 were moved to the
Apach2 namespace, we'd do *something like* that.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> Those of us who use Apache apps would have to do something like this:
>
> eval "use Apache2";
> use Apache if $@;
What does it mean? You never need to touch Apache2.pm in your mp2
application. It's not part of the API and you should not use it.
It's only used at the config file to load the right mod_perl. It's a user
who will do that if and only if they have 2 modperls installed. It's
documented here:
http://perl.apache.org/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules
I guess the doc should link back to
http://perl.apache.org/docs/2.0/user/install/install.html#MP_INST_APACHE2
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by David Wheeler <da...@kineticode.com>.
On Jan 2, 2005, at 11:12 AM, Joe Schaefer wrote:
> I don't think we'd have too much trouble getting
> comfortable with a "mod_perl" -> "mod_perl2"
> rename, but the difficult question is what to do
> about Apache::. A rename may make sense for the
> bare-metal libraries like Apache::Request (what
> to actually call it is a different issue, because
> the 2.x version is really an APR:: application).
APR::Request?
> But a rename wouldn't make sense for something like
> Apache::ASP.
Those of us who use Apache apps would have to do something like this:
eval "use Apache2";
use Apache if $@;
If we wrote our apps to the Apache1 API, we could perhaps use some sort
of Apache2::compat module to ensure backwards compatibility. Otherwise,
we might have to use some if/then statements. But if my use of mp1 is
any indication, that wouldn't be too much work.
> Waiting for King Solomon to appear isn't going to lead
> us anywhere. The community needs an actionable proposal
> to kick around if you're pining for real change.
I'm not pining for real change. I'm pining for an open and welcome
cheer from all parties upon the release of mp2. With the current
approach, we're clearly not going to get it, and that will be to the
detriment of mp2. I think that would be sad, and am willing to make
sacrifices in how I have to maintain my own code (to be compatible or
not) in order to avoid it. I suspect that other modules authors who use
the mp API would agree.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
David Wheeler <da...@kineticode.com> writes:
> On Jan 1, 2005, at 8:24 AM, Stas Bekman wrote:
>
>> But they don't understand that mod_perl is 10 times more complex
>> and different from what they are used to deal with, no matter how
>> many hundreds of CPAN modules they have released so far.
>
> That, to me, is reason enough to move it to another namespace.
I don't think we'd have too much trouble getting
comfortable with a "mod_perl" -> "mod_perl2"
rename, but the difficult question is what to do
about Apache::. A rename may make sense for the
bare-metal libraries like Apache::Request (what
to actually call it is a different issue, because
the 2.x version is really an APR:: application).
But a rename wouldn't make sense for something like
Apache::ASP.
Waiting for King Solomon to appear isn't going to lead
us anywhere. The community needs an actionable proposal
to kick around if you're pining for real change.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by David Wheeler <da...@kineticode.com>.
On Jan 1, 2005, at 8:24 AM, Stas Bekman wrote:
> But they don't understand that mod_perl is 10 times more complex and
> different from what they are used to deal with, no matter how many
> hundreds of CPAN modules they have released so far.
That, to me, is reason enough to move it to another namespace.
Regards,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> And that's why Apache2_2 won't be necessary. If Apache2 becomes
> Apache3 because they rewrite everything from scratch again, then we
> release mp3 with Apache3:: prefixes!
unfortunately, I don't think that is entirely true. one of my Apache 2.x
modules, Apache::IncludeHook, is an XS wrapper around some mod_include
things. mod_include was entirely rewritten between 2.0 and 2.2 such that
the XS is completely incompatible between versions. so, to support this
particular module in 2.0 and 2.2 I would need two separate modules (or some
really complex acrobatics, but if that were acceptable we wouldn't be having
this discussion, really).
the general thought within httpd (or at least my read of it) is that they
are comfortable with semi-major API changes for minor even numbered
versions, so I suspect there are likely to be other cases like this as time
moves on.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Joe" == Joe Schaefer <jo...@sunstarsys.com> writes:
Joe> Yes, I think we would actually. Because moving from mp1
Joe> to mp2 always necessitated a webserver change, so you can't
Joe> simply mark it as a CPAN upgrade from mp1 and expect some
Joe> random mp1 app-server to be happy about the "upgrade".
This is also my fundamental complaint. mp2 is a *different* product,
because it works with an entirely different *non-dropin-replacement*
webserver, Apache2.
I can't "upgrade" my mp1 with mp2 because mp2 doesn't play with
Apache1, and mp1 doesn't play with Apache2. That's why, for the
current toolchain, it must have a different namespace, because it's
not an "upgrade". It's a *new product*.
And that's why Apache2_2 won't be necessary. If Apache2 becomes
Apache3 because they rewrite everything from scratch again, then we
release mp3 with Apache3:: prefixes!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Adam Kennedy <ad...@phase-n.com> writes:
[...]
> If you had kept mod_perl 2 completely compatible with mod_perl 1 you
> wouldn't need to use Apache2:: at all, and we wouldn't be in this
> situation.
Yes, I think we would actually. Because moving from mp1
to mp2 always necessitated a webserver change, so you can't
simply mark it as a CPAN upgrade from mp1 and expect some
random mp1 app-server to be happy about the "upgrade".
It's a platform shift, and up until very, very recently,
the community was comfortable with the idea of letting that
happen without breaking their existing mp1 apps via the
Apache2.pm thingy.
By the way, moving a private discussion into a public
place shouldn't happen without the prior consent of the
other party. I trust that's not happening here.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Adam Kennedy <ad...@phase-n.com>.
To the list:
Again, I've brought this back in, which wasn't meant to be private in
the first place, but was mis-sent.
I'll try to keep everything as transparent as possible in future.
Stas Bekman wrote:
> Adam Kennedy wrote:
>
>> >> Putting aside for the moment the relationship of these to
>> >> their mp1 counterparts, it shouldn't be too hard to come up
>> >> with alternate, descriptive names, either in an Apache2::*
>> >
>> >
>> > -1 to embedding numbers in API
To those catching up, here is the general solution for why Apache2_2::
won't be necessary.
>> We aren't embedding version numbers in the API, we are embedding the
>> API in the module name. perl.apache.org documents two APIs. The
>> "Apache mod_perl 1 API" and the "Apache mod_perl 2 API".
>>
>> And as such, you would have the Apache:: namespace for the mod_perl 1
>> API, and Apache2:: for the mod_perl 2 API.
>>
>> It's the API revision that is determining the module name, not the
>> implementation version.
>>
>> Apache:: -> mod_perl 1 API ( Apache 1.0, 1.1, 1.2, 1.3 )
>> Apache2:: -> mod_perl 2 API ( Apache 2.0, 2.2, 2.4, 2.6... )
>>
>> As long as you do what everyone else is expected to do and maintain
>> API stability, you can keep using Apache2:: regardless of what happens
>> to the underlying Apache server.
>>
>> The only reason to have to use a new namespace would be if you plan to
>> incompatibly break the API every single time Apache goes through a
>> revision.
Please note by "incompatibly" I mean "fatally incompatible". That is, a
complete change. Small API changes are expected and people can generally
deal with this.
>> You aren't planning to do that are you? Now THAT would REALLY piss off
>> the user base.
>
>
> Why have you chosen yourself as someone who knows what thousands of
> other people think?
Because I've done enough programming, and met enough developers, and
talked to enough people on this issue to say it. Many many people are
saying these things.
>> >> or ModPerl::* namespace, or perhaps just something different
>> >> under Apache:: (eg, Apache::Utility).
>> >
>> >
>> > That's wrong, Randy. What you gonna do when mp2.2 is released,
>> which may
>> > happen any moment, now that Apache 2.2 is getting ready for its
>> release.
>> > Rename those again? And again for 2.4? ...
>>
>> You keep asking this, and to my distress noone else form the perl
>> community seems to have answered you.
>>
>> You use Apache2::... it's the same API and it's going to be unchanged
>> when Apache 2.2 comes out, and when Apache 2.4 comes out. You might
>> add a few new features, but it's normal to add features to APIs. It
>> doesn't break anything.
>
>
> That's exactly why I'm saying that you don't understand the
> Apache/modperl internals. The change from 2.0 to 2.2 might and will be
> incompatible for certain features. So if we do Apache2 we must do
> Apache2_2, and so forth.
Then if you choose to make small changes, you document them. This is
quite normal. It doesn't require API changes.
The only time you need to move to a new namespace, it is because you are
going to break EVERYTHING, as has happened with mod_perl 2.
If you had kept mod_perl 2 completely compatible with mod_perl 1 you
wouldn't need to use Apache2:: at all, and we wouldn't be in this situation.
>> > -1
>> >
>> > mp2.2 will have mod_perl2_2.pm?
>> >
>> > Don't forget that you will need to rename APR.pm as well
>>
>> If the APR:: perl API doesn't change, you don't need to change the name.
>
>
> That's very inconsistent. So you will have a mix of Apache2_2/Foo and
> Apache2/Bar in the same distro? That's insane.
APR:: is a separate library and a separate API, or so I believe. I'll
look at this later, but I'm curious what the reason was for not
packaging APR:: separately, so that applications that need APR:: but
don't need mod_perl don't have to install apache.
>> Yet again you summarily dismiss the perl community.
>
>
> I'm sorry, I fail to see the whole perl community presented by a few
> individuals. I don't dismiss the community, I disagree with those few
> individuals.
As I said before, I listed a number of people willing to be named in
public, and I also indicated that I have not yet encountered a single
person who supports API overloading or "multiple incompatible stable
APIs in the module name".
>> I'm not just making this shit up.
>>
>> Perl on the web is ALREADY being marginalized by PHP. At the low end
>> where convenience and installability matter FAR more than performance
>> PHP has been kicking our ass for several years now.
>>
>> It's getting harder to find decent people because every bloody person
>> seems to be starting their web-stuff attempts with PHP. And it's hurting.
>>
>> mod_perl is still very useful for big projects, but PHP is eroding
>> from the bottom.
>
>
> And the thing you and Randal have started are doing a fantastic job and
> bringing it further down. You should enroll to PHP as an achievement gift.
What we have done so far is not in the general public eye, it's on
product specific mailing lists. I wouldn't be doing this if I didn't I
had to.
Taking no action on this will be far worse than taking action.
>> If mod_perl is going to get even worse to install, and the standard
>> perl tools don't support it, and installing the CPAN modules is going
>> to be a pain, if not impossible, we are going to lose even more of our
>> userbase.
>
>
> I disagree with that. But you know that already.
>
>> (RANT REMOVED)
>>
>> I wrote the rant offline and it's outlines a solution path I _really_
>> don't want to follow. He's since emailed me offline, and as long as
>> the mod_perl community is willing to pause for long enough for people
>> to get back from holidays and discuss this properly, I see no reason
>> to start getting desperate.
>
>
> Eh? What's that?
>
Since I've had a few people emailing me to say that I should be
addressing the whole community and that you are not the one that has to
make these decisions, at this point I'm going to hold and wait for their
interaction on this subjects.
I'll outline my next steps only if it appears people aren't going to
wait and talk amicably. Because then things start to get worse and I
don't want that.
I'm willing to trust that the general mod_perl community will see that a
pause and proper communication if a better option.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] taking a step back?
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> Although this may not be the best time to raise this, the
> strong opinions being expressed, plus the shortness of time
> on the part of the many of us, perhaps we could look at what
> would be involved to move the modules in the mp2 core so as
> not to conflict with mp1. If I counted right, there's not
> that many:
>
> Apache::Log
> Apache::PerlSections
> Apache::Resource
> Apache::SizeLimit
> Apache::Status
> Apache::URI
> Apache::Util
>
> Putting aside for the moment the relationship of these to
> their mp1 counterparts, it shouldn't be too hard to come up
> with alternate, descriptive names, either in an Apache2::*
-1 to embedding numbers in API
> or ModPerl::* namespace, or perhaps just something different
> under Apache:: (eg, Apache::Utility).
That's wrong, Randy. What you gonna do when mp2.2 is released, which may
happen any moment, now that Apache 2.2 is getting ready for its release.
Rename those again? And again for 2.4? ...
I can see s/Apache/ModPerl/ for:
Apache::PerlSections
Apache::Resource
Apache::SizeLimit
Apache::Status
since those aren't Apache API really, so they could be moved like Registry
modules did. Apache::Reload is another one.
These are Aapache API:
Apache::URI
Apache::Util
Apache::Log
and can't be moved to ModPerl::.
> The question of mod_perl.pm itself is different. In the mp2
> distribution, in a sense this is used to "brand" the whole
> package - give it a version, and a pod NAME and description.
> Although I see Stas' argument about not having a mod_perl.pm
> and mod_perl2.pm in the same package, what about just
> renaming mod_perl.pm to mod_perl2.pm? And in keeping with
> the use of mod_perl.pm to give an abstract that
> search.cpan.org can use for the mod_perl distribution,
> renaming the mp2 distribution itself to mod_perl2. If one
> sees the use of mod_perl.pm as just representing the
> package, then calling it mod_perl2.pm may not be too
> unnatural, given that Apache1 modules are fundamentally
> different from Apache2 modules.
-1
mp2.2 will have mod_perl2_2.pm?
Don't forget that you will need to rename APR.pm as well
mod_perl.pm is a part of the modperl API. mod_perl.pm's API didn't change,
so there is no logical reason to change that.
> There's at least two questions that immediately arise with
> this. The first - how much physical work would it be to do
> this renaming? Quite a bit, I imagine, but a finite amount -
> I'd be willing to set aside some time in the immediate
> future to work on this. The bigger issue is how such a
> change would affect existing 3rd party code that currently
> uses mp2? This may cause quite a bit of headaches -
> "legally" I guess one is free to do this, since mp2 isn't
> officially released yet, but one doesn't want to alientate
> existing users. I fear, though, that if mp2 gets
> marginalized, even in the short term, by a (sizeable)
> segment of the general Perl community, this would be a
> bigger long-term problem for early adopters. This might not
> happen, of course, but is it worth the gamble? Perhaps, as a
> stop-gap measure, one could make up a compatibility layer,
> similar to Apache::compat, that would assist in the
> change-over.
I say that mp2-gets-marginalized-fear talk is BS and FUD.
[...]
> Again, I raise the above not necessarily because it's the
> best solution within the mp2 environment, but because of the
> pretty strong opinions expressed on the other side.
The other side doesn't understand the problem and you can safely ignore
them. They are perfectly logical and correct to say the things regarding
the perl modules they are used to. But they don't understand that mod_perl
is 10 times more complex and different from what they are used to deal
with, no matter how many hundreds of CPAN modules they have released so far.
I say let it go, this is a futile battle, it's useless trying to spend any
more time to convince that other side that they dig in the wrong place.
The amount of time people have spent so far trying to convince us that we
are wrong, could have been used to already implement the required changes
in PAUSE and CPAN. But no, people prefer to talk...
> And Happy New Year!
Happy New Year.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org