Re: Re: [PEPr] Comment on Web Services::Services_Digg

On 4/22/07, Gregory Beaver <greg@chiaraquartet.net> wrote:

Alexey Borzov wrote: Hi, Gregory Beaver wrote:

Alexey Borzov (http://pear.php.net/user/avb) has commented on the proposal for Web Services::Services_Digg. Comment: The package may not have HTTP_Request as a required dependency since HTTP_Request is not a E_STRICT compatible package, see http://pear.php.net/pepr/pepr-proposal-show.php?id=419

There is no E_STRICT alternative to HTTP_Request, I strongly recommend we allow dependencies on older packages when there is no alternative.

I strongly recommend going the other way round and "fix" the package in question instead of fixing the rules each time. One of the goals of my E_STRICT RFC was to encourage the rewrite of base packages like HTTP_Request to PHP5 (yes, I know that I'm its maintainer, but outside help won't do any harm). Hi, Everyone is in favor of newer packages to implement better fixes for the problems solved by the old packages. Should we then simply reject new packages like Services_Digg if they do depend on existing non-E_STRICT packages? I fear that this is a good way to deter developers from joining PEAR (not in Joe's case, he's been around, but others who lurk on the list will see this). Since the E_STRICT RFC was accepted, how many packages have in fact been rewritten to support E_STRICT? On my quick scan of the packages list, here are 5 packages out of about 350 or so PHP4-based packages. We have on the other hand, had many new submissions of PHP5-based packages. I am pretty sure that if we *really* want to encourage people to re-develop existing solutions in PHP 5, there needs to be more carrot than stick. In other words, rather than punishing people who submit packages that are written in PHP 5 but depend upon older solutions, we need to create a good reason for developers to devote time to fixing up an old solution into the new language features. Frankly, all of the energy devoted to re-inventing the wheel in PHP 5 is happening in the Zend Framework, but even there, they have rules that prevent innovation from happening at its full possible speed. Ironically, considering our current topic, just a few weeks ago I saw that a user had already ported HTTP_Request to PHP 5, and proposed it to Zend. Zend rejected it as it was not written from scratch, so we are not alone in having our set of peculiar rules (all for good reasons, of course, but it doesn't make them any less peculiar). The real question, as I see it, is why that user then did not turn around and propose his changes to PEAR? There is a public perception that outsiders are not welcome to provide major changes to existing packages, and very few people have pierced the veil to see that in fact innovation is welcome in PEAR. Truthfully, every time I think about proposing a change to someone else's package, I get this fear that someone will yell at me for doing something wrong, and if *I* get that feeling, what are the odds that someone who hasn't been hacking on PEAR for years will get that feeling too? I think it might be a good time to take a look at how we can channel the creative energies of new contributors. The other day, someone on IRC mentioned that they would like to see package requests for PEAR. I would like to refine this idea a bit, and have per-collective roadmaps, where users can request a solution to a problem, which can then be assigned to the roadmap for a collective. This would allow those of us inside PEAR to request, for instance, a PHP5-based implementation of Net_Socket, and visibly assign it to a collective's roadmap. Then, if we rework the front page of pear.php.net and provide a "Want to help out?" link, I suspect we will find the conversion rate of existing packages will climb significantly. As for the spat between Alexey and David, I trust you will both work out the differences. From my vantage point, I don't see a problem here. Both Alexey and David have shown strong commitment to improving PEAR. David is offering to help out with coding the new HTTP_Request, and Alexey wants people to help out. Let's try to keep things friendly unless there's a serious reason for warring words.

We have worked the problem out :)

Thanks, Greg

-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18