Mailing List Archive

Everybody needs to "STEP BACK" and realize how much work and soul Stas
has put into mod_perl.
He deserves A LOT OF CREDIT. Keep up the Good work Stas.


Paul


Stas Bekman wrote:

> Andreas J Koenig wrote:
>
>>>>>>> On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman
>>>>>>> <stas@stason.org> said:
>>>>>>
>>
>>
>> >> Will it not also affect us who build mod_perl applications and want
>> >> an easy-to-use installer to just work for people who download our
>> >> software? Frankly, I don't think that it should be fine for just the
>> >> dedicated mod_perl developer. This is one place where PHP is kicking
>> >> the crap out of us.
>>
>> > us == perl, once PAUSE is fixed, and CPAN clients are adjusted,
>> it will > just work.
>>
>> Stas, please stop propagating this fairy tale. The danger is, that
>> people will believe you. This I call unfair propaganda as it tries to
>> put the blame on somebody else's shoulders. That's not a very
>> promising strategy to solve problems.
>>
>> Listen carefully: it is very unlikely that PAUSE and CPAN get
>> ''''fixed'''' as you call it. There is no solution at hand and 4
>> people who you know well and who in turn know the problem domain very
>> well have agreed and have told you so.
>>
>> So please stop telling untruth.
>
>
> Andreas, what exactly do you call untruth? My attempt to make
> PAUSE/CPAN better and accomodate the growing community needs? Why is
> that untruth?
>
> It's not a danger that people will believe me, it's a hope. If enough
> people believe in that may be things will change. Things shouldn't be
> cast in stone and they should evolve as the world evolve.
>
> I truly don't understand why you refuse to believe that CPAN/PAUSE
> needs to grow.
>
> Re: About putting the blame on other shoulders
>
> It's not putting blame on other shoulders. It's an attempt to actually
> solve things. You know very well, that I didn't just say it's
> PAUSE/CPAN problem. I've spent hours trying to find a solution. I've
> even found a person who have agreed to implement the required changes.
> And all you can say: "put the blame on other shoulders"? thanks so
> much for giving me so much credit.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

Cure wrote:
> Everybody needs to "STEP BACK" and realize how much work and soul Stas
> has put into mod_perl.
> He deserves A LOT OF CREDIT. Keep up the Good work Stas.

Thanks Cure, for the kind words...

but we are talking about a different kind of credit here. Andreas has
put just as much work and soul if not more into PAUSE/CPAN. I was talking
about the credits of actually trying to resolve the current conflict,
rather than just trying to make someone else do the work.

--
__________________________________________________________________
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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

>>>>> On Tue, 28 Dec 2004 10:54:27 -0500, Stas Bekman <stas@stason.org> said:

> Cure wrote:
>> Everybody needs to "STEP BACK" and realize how much work and soul
>> Stas has put into mod_perl.
>> He deserves A LOT OF CREDIT. Keep up the Good work Stas.

Actually, I love Stas. And I'm sure he knows that.

> but we are talking about a different kind of credit here. Andreas has
> put just as much work and soul if not more into PAUSE/CPAN. I was talking
> about the credits of actually trying to resolve the current conflict,
> rather than just trying to make someone else do the work.

I was referring to the sentence.

once PAUSE is fixed, and CPAN clients are adjusted, it will just work.

This is what gives the reader the false impression that (1) only PAUSE
and CPAN clients need to be fixed, that (2) there is an agreed-upon
way of fixing it, and (3) somebody will do just that.

All three claims are very unlikely to be true.

--
andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

I personally side with Stas' intentions (if I understand them correctly) on
the matter - it makes it easy for developers to work with both versions of
mod_perl.

I really don't see what the loaded guns are about - each side here deserves
*lot* of credit for pointing out a big problem.

On the one hand, if people don't want to budge, and are saying it makes too
much of a mess to continue trying to work around Stas' propsed "use Apache2"
and suite of "MP::" installation tools, perhaps it's not unreasonable to
simply force mp2 users to set up a seperate Perl installation? After all,
users must set up seperate Apache distributions for mp 1 and 2. When you
think about it, it's really a 2 way relationship: you're "importing the
Apache API into Perl", as much as you're "embedding the Perl interpreter
into Apache". Just like you can't use one Apache/mod_perl with two
installations of Perl (say 5.6 and 5.8 on mod_perl1), it's fair to demand
that you shouldn't use two versions of Apache/mod_perl (1.3/2.x) with one
version of Perl. Chances are that a majority of people with mod_perl1/2 on
the same machine are developers, and porting things over (or maintaining
modules for both, or something else which is intelligent) - they'll all know
how to install both in parallell "the hard way" (eg, setting up 2 perl
installations); the majority of the non-developers are likely poor sysadmins
who don't quite understand what they're getting themselves into with
parallel installations, and we possibly shouldn't be giving them a trivial
way to do it.

However, instead of "the opposition" making your collective point (And you
DO have a good point), maybe you should take Stas' advice and actually think
about the bigger problem: mod_perl is an embedded interpreter; ANY embedded
Perl interpreter might have to deal with similar difficulties invovled with
sharing modules. For example, what if I had multiple applications that all
used an embedded interpreter - and each of those embedded interpreters
needed a different version of the same Perl module(s).
By fighting down Stas now, you're potentially closing the door to other
applications which deal with an embedded Perl interpreter, since they may
not be able to coexist with other such applications (or even with the
"normal" Perl interpreter), since there's only one "site" directory, which
any application linked to the Perl shared object MUST share, and you can
only have one version of any module installed at any given point.

Maybe I'm completly misunderstanding why Stas put all the effort into his
framework to support; maybe my objections make no sense. But in any case,
please STOP ARGUING - you're making a public spectacle that's gonna bash
Perl in general as much as mod_perl specifically Many of you sound like
offended six year olds, and it's going to become embarassing. One of the
big points of Perl is TMTOWTDI - there isn't supposed to be "one way to do
it", and just because everyone (myself included) is being lazy and not
setting up dual Perl installations, since Stas was nice enough to provide a
rudimentary workaround for it, you can't expect Stas's workaround to be
"perfect" - he's got enough to deal with with mod_perl development without
having to deal with how to fix Perl/CPAN's inability to support installation
of multiple versions of modules.

Anyway, the fact is that this *does* seem to be a pretty heated flame war,
so I'll shut up now before I get myself into more trouble than I already
have.

Issac

----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "Andreas J Koenig" <andreas.koenig.gmwojprw@franz.ak.mind.de>
Cc: "David Wheeler" <david@kineticode.com>; <advocacy@perl.apache.org>;
"mod_perl Mailing List" <modperl@perl.apache.org>; "Randal L. Schwartz"
<merlyn@stonehenge.com>
Sent: Tuesday, December 28, 2004 5:01 PM
Subject: Re: About putting the blame on other shoulders


> Andreas J Koenig wrote:
>>>>>>>On Tue, 28 Dec 2004 00:09:07 -0500, Stas Bekman <stas@stason.org>
>>>>>>>said:
>>
>>
>> >> Will it not also affect us who build mod_perl applications and want
>> >> an easy-to-use installer to just work for people who download our
>> >> software? Frankly, I don't think that it should be fine for just the
>> >> dedicated mod_perl developer. This is one place where PHP is kicking
>> >> the crap out of us.
>>
>> > us == perl, once PAUSE is fixed, and CPAN clients are adjusted, it
>> will > just work.
>>
>> Stas, please stop propagating this fairy tale. The danger is, that
>> people will believe you. This I call unfair propaganda as it tries to
>> put the blame on somebody else's shoulders. That's not a very
>> promising strategy to solve problems.
>>
>> Listen carefully: it is very unlikely that PAUSE and CPAN get
>> ''''fixed'''' as you call it. There is no solution at hand and 4
>> people who you know well and who in turn know the problem domain very
>> well have agreed and have told you so.
>>
>> So please stop telling untruth.
>
> Andreas, what exactly do you call untruth? My attempt to make PAUSE/CPAN
> better and accomodate the growing community needs? Why is that untruth?
>
> It's not a danger that people will believe me, it's a hope. If enough
> people believe in that may be things will change. Things shouldn't be cast
> in stone and they should evolve as the world evolve.
>
> I truly don't understand why you refuse to believe that CPAN/PAUSE needs
> to grow.
>
> Re: About putting the blame on other shoulders
>
> It's not putting blame on other shoulders. It's an attempt to actually
> solve things. You know very well, that I didn't just say it's PAUSE/CPAN
> problem. I've spent hours trying to find a solution. I've even found a
> person who have agreed to implement the required changes. And all you can
> say: "put the blame on other shoulders"? thanks so much for giving me so
> much credit.
>
> --
> __________________________________________________________________
> 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: advocacy-unsubscribe@perl.apache.org
> For additional commands, e-mail: advocacy-help@perl.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

Issac Goldstand wrote:
[...]

> After all, users must set up seperate Apache
> distributions for mp 1 and 2. When you think about it, it's really a 2
> way relationship: you're "importing the Apache API into Perl", as much
> as you're "embedding the Perl interpreter into Apache". Just like you
> can't use one Apache/mod_perl with two installations of Perl (say 5.6
> and 5.8 on mod_perl1), it's fair to demand that you shouldn't use two
> versions of Apache/mod_perl (1.3/2.x) with one version of Perl.
> Chances are that a majority of people with mod_perl1/2 on the same
> machine are developers, and porting things over (or maintaining modules
> for both, or something else which is intelligent) - they'll all know how
> to install both in parallell "the hard way" (eg, setting up 2 perl
> installations); the majority of the non-developers are likely poor
> sysadmins who don't quite understand what they're getting themselves
> into with parallel installations, and we possibly shouldn't be giving
> them a trivial way to do it.

Unfortunately thanks to Randal, people are now totally confused.

Issac, this is not the problem we are trying to solve. The problem is that
PAUSE indexes only one version of a package name. Forget all the 'use
Apache2' and other issues for now. There are all minor issues, compared to
the indexing problem.

> Maybe I'm completly misunderstanding why Stas put all the effort into
> his framework to support; maybe my objections make no sense. But in any
> case, please STOP ARGUING - you're making a public spectacle that's
> gonna bash Perl in general as much as mod_perl specifically

You can send special thanks to Randal, who in the thread asking to help to
test the upcoming realease to spot any problems, suggests the opposite:
http://apache.slashdot.org/comments.pl?sid=133957&threshold=0&commentsort=0&tid=145&mode=nested&cid=11186211

> Many of you
> sound like offended six year olds, and it's going to become
> embarassing. One of the big points of Perl is TMTOWTDI - there isn't
> supposed to be "one way to do it", and just because everyone (myself
> included) is being lazy and not setting up dual Perl installations,
> since Stas was nice enough to provide a rudimentary workaround for it,
> you can't expect Stas's workaround to be "perfect" - he's got enough to
> deal with with mod_perl development without having to deal with how to
> fix Perl/CPAN's inability to support installation of multiple versions
> of modules.

And to give the right credits, it's not 'Stas' framework', there is a
group of developers working on this. And it wasn't even me who wrote most
of the things and workarounds. The credits should really go to Doug
MacEachern. I just happen to push things forward at the moment, where
others have left. And somebody else will do that later on. modperl is not
a one man's project.

--
__________________________________________________________________
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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

>>>>> "Stas" == Stas Bekman <stas@stason.org> writes:

Stas> Unfortunately thanks to Randal, people are now totally confused.

No, I think thanks to me, people are now aware of a problem of
fundamental incompatibility between the "single @INC" historical
legacy of the entire Perl world and toolchain, and your "use Apache2"
workaround. There's awareness, not confusion. I think *you* are
trying to confuse the issue by saying there's not a single thing wrong
with your proposed release of MP2. Yes, there wouldn't be, if the
entire rest of the world was compatible with it, which it isn't.

Here are some possible scenarios:

1) you don't budge, CPAN doesn't change, and people around the world
get confused with your release, because it's asking them to "upgrade"
their mp1 by installing mp2, which *cannot* be done.

2) you don't budge, the rest of the world changes, toolsets get altered,
everyone upgrades their tools just to avoid #1. I think this is
what you want, but a lot of resources and a lot of people have to bend
to your beck and call to make this happen, and it's not gonna happen
by mid January.

3) you don't release mp2 to the CPAN except as an "experimental" version
number, which avoids indexing, and people who want it can ask for it
by name directly, not via "install mod_perl".

4) you figure out how to rename all mp2 modules that aren't upward
implementation compatible with mp1 to a new namespace, and release
that like any of the other 72,000 modules on the CPAN.

5) something else entirely.

I'm just saying that #1 and #2 are both unacceptable to me. I think
it's also unacceptable to a lot of others. So we need to look at #3,
#4, and #5.

Now, if everyone involved agrees that #1 or #2 are workable, that's
fine too. But I want this to be a community decision, not just "Stas
forcing pollution into everyone else's lives".

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

----- Original Message -----
From: "Randal L. Schwartz" <merlyn@stonehenge.com>
To: "Stas Bekman" <stas@stason.org>
Cc: <advocacy@perl.apache.org>; "Andreas J Koenig"
<andreas.koenig.gmwojprw@franz.ak.mind.de>; "mod_perl Mailing List"
<modperl@perl.apache.org>
Sent: Tuesday, December 28, 2004 6:43 PM
Subject: Re: About putting the blame on other shoulders


>>>>>> "Stas" == Stas Bekman <stas@stason.org> writes:
>
> Stas> Unfortunately thanks to Randal, people are now totally confused.
>
> No, I think thanks to me, people are now aware of a problem of
> fundamental incompatibility between the "single @INC" historical
> legacy of the entire Perl world and toolchain, and your "use Apache2"
> workaround. There's awareness, not confusion. I think *you* are
> trying to confuse the issue by saying there's not a single thing wrong
> with your proposed release of MP2. Yes, there wouldn't be, if the
> entire rest of the world was compatible with it, which it isn't.
>
> Here are some possible scenarios:
>
> 1) you don't budge, CPAN doesn't change, and people around the world
> get confused with your release, because it's asking them to "upgrade"
> their mp1 by installing mp2, which *cannot* be done.

Which is exactly the point that I was trying to make: This *should* be
doable. The fact that it's *not* means that Perl is a monolithic library
and can't have 2 sets of "extensions" in the same site installation. Which
means that libperl.so is something which shouldn't exist, since it implies
some "sharedness" - but what it's really providing is a shared library
interface with static extensions. By linking against libperl.so (or
whatever), you're essentially dooming your applications to being stuck with
whatever CPAN throws its way.

Issac


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

>>>>> "Issac" == Issac Goldstand <margol@beamartyr.net> writes:

Issac> Which is exactly the point that I was trying to make: This *should* be
Issac> doable. The fact that it's *not* means that Perl is a monolithic
Issac> library and can't have 2 sets of "extensions" in the same site
Issac> installation.

*Or* in the CPAN, or visible to perldoc, or with installed manpages.
See, the whole toolchain presumes "Apache::Request" or "mod_perl"
means precisely one thing.

It doesn't matter how many Perl installations you have on your disk.
There's only one CPAN. Perrin's point, while valid, doesn't address
the indexing issue.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

----- Original Message -----
From: "Randal L. Schwartz" <merlyn@stonehenge.com>
To: "Issac Goldstand" <margol@beamartyr.net>
Cc: <advocacy@perl.apache.org>; "Andreas J Koenig"
<andreas.koenig.gmwojprw@franz.ak.mind.de>; "mod_perl Mailing List"
<modperl@perl.apache.org>; "Stas Bekman" <stas@stason.org>
Sent: Tuesday, December 28, 2004 7:09 PM
Subject: Re: About putting the blame on other shoulders


>>>>>> "Issac" == Issac Goldstand <margol@beamartyr.net> writes:
>
> Issac> Which is exactly the point that I was trying to make: This *should*
> be
> Issac> doable. The fact that it's *not* means that Perl is a monolithic
> Issac> library and can't have 2 sets of "extensions" in the same site
> Issac> installation.
>
> *Or* in the CPAN, or visible to perldoc, or with installed manpages.
> See, the whole toolchain presumes "Apache::Request" or "mod_perl"
> means precisely one thing.

Just like when GD2 was put out 2 1/2 years ago, there was only the old "GD"
in CPAN, and I had the same problems - I had to check every piece of code I
wrote for GD, and rewrite it to work with the new GD, as well as specify
that I now "use GD 2;" thus destroying any backwards compatability.

> It doesn't matter how many Perl installations you have on your disk.
> There's only one CPAN. Perrin's point, while valid, doesn't address
> the indexing issue.

But the indexer *does* handle it. If I want to install an old version of
GD, because I can't install libgd2, I can still do "install
L/LD/LDS/GD-1.41.tar.gz" (finding the path is usually easy, unless
maintainers were switched: just do "m GD") It would be still better, IMHO,
if I could just do "install GD-1.41". The problem is that modules/programs
which want GD-1.xx will choke on GD-2.xx and vice versa (and I can only have
one in the site installation at the same time). And to make things worse,
the "use module version" pragma only goes one way: up.

Issac


---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org

I might have misunderstood , Sorry. I just love mod_perl so much :)

Paul




Andreas J Koenig wrote:

>>>>>>On Tue, 28 Dec 2004 10:54:27 -0500, Stas Bekman <stas@stason.org> said:
>>>>>>
>>>>>>
>
> > Cure wrote:
> >> Everybody needs to "STEP BACK" and realize how much work and soul
> >> Stas has put into mod_perl.
> >> He deserves A LOT OF CREDIT. Keep up the Good work Stas.
>
>Actually, I love Stas. And I'm sure he knows that.
>
> > but we are talking about a different kind of credit here. Andreas has
> > put just as much work and soul if not more into PAUSE/CPAN. I was talking
> > about the credits of actually trying to resolve the current conflict,
> > rather than just trying to make someone else do the work.
>
>I was referring to the sentence.
>
> once PAUSE is fixed, and CPAN clients are adjusted, it will just work.
>
>This is what gives the reader the false impression that (1) only PAUSE
>and CPAN clients need to be fixed, that (2) there is an agreed-upon
>way of fixing it, and (3) somebody will do just that.
>
>All three claims are very unlikely to be true.
>
>
>

On Tue, 28 Dec 2004 19:30:28 +0200, Issac Goldstand
<margol@beamartyr.net> wrote:
> the "use module version" pragma only goes one way: up.
>
> Issac

it's possible to trap the requested version number in your module and provide
the interface given by earlier versions when that is requested, but
it's a PITA and
an even bigger PITA if you want to support different versions getting
asked for in
different modules used within the same running system.

Here's how to do it: within the import() function, store some behavior hints
to dynamic scalars with huge and unlikely names beneath the caller's name
space and refer to them whenver making version-specific choices.
Your module then gets bogged down with run-time polymorphism like so:

no strict;
return (
# before version 7 this function returned a four-long arrayref
${caller().'::MyModule::VersioningSwitches::hashresults'} ?
\%result : [@result{qw/foo bar baz blarfl/}]
)

A better, more robust solution, which few do, and which would have avoided
the current debate, is to move version numbers implying incompatibility into the
name of the module rather than the version number. If GD 2 had been
released as GD2,
if mod_perl 2 goes onto CPAN as modperl2, if all interface-changing new releases
append numbers to the module name rather than pretending to be new releases
of old interfaces, since the updating automatons don't grok the
distinction, instead
of trying to get them to, and if this proposed standard nomenclature convention
can be somehow backdated several years, the world would be a better place would
it not?


--
David L Nicol
You're striving for harmony, and, if you try to take
too much, you'll come to grief. -- Michael Redmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org