wiki page for HTTP_Request2 inside (was: Re: [PEAR-DEV] Re: [PEPr] Comment on Web Services::Services_Digg)

Hi, Gregory Beaver wrote:

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).

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).

As I already stated, one of the goals of my RFC (which passed with +16 half a year ago, so I am a bit curious why there are so many people acting surprised *now*) was to encourage the rewrite of "base" packages. I'd also like to remind that there was a list of "base" packages posted: http://marc.info/?l=pear-dev&m=115264520301256&w=2 and HTTP_Request had a prominent position in the top priority list *back then*. So the real question we should be answering is not "how do we weasel Services_Digg into PEAR?" but "how do we encourage rewrite of 'base' packages at last?".

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.

...thus we should change our rules so that it won't even be necessary to rewrite PHP4 packages. Nice. :)

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.

Here I agree. Now, what would you suggest as a carrot?

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.

I think a good idea would be to ask that particular user rather than guess. But you are probably right about the perception thing. In any case, I created a wiki page for HTTP_Request2 http://quickform.mamasam.com/wiki/http_request2 so those interested may register there and add their ideas / suggestions (the wiki's primary purpose is QuickForm2 development, so those interested may add their ideas for QF2 as well). IMO, before we even start working on the package itself, we should solve the dependencies issue and try to contact Philippe Jausions to get the stuff he presumably did for HTTP_Request.