Re: RE: Zend +Paypal = PEAR::SOAP??

I agree, a company's investment is orthogonal to contributions to the package. I signed up as a maintainer to fix the bugs that came up in our use of PEAR::SOAP at Avaya on a product in development. No company wants to fork an open source package with their own branch of fixes. Only a few companies actively sponsor open source development, while the majority are consumers of the packages and just want to ensure reliability, security, stability, and all the other -ilities. If there are other bugs that need to be fixed, or features that would be nice to have, that aren't needed by the product then it's really what I want to do on my own time as a hobbyist. As it turns out, we didn't find any problems and required no additional features, changes, or bug fixes -- PEAR SOAP was an excellent solution. Back to the case in point here, I had thought they were back-porting the SOAP C-extension to PHP4 for enhanced performance. In practical application testing, I've noticed that gSOAP (C++) can get under 10ms/request, while Axis(Java) can get around 30-50ms/request, while I have never seen PEAR::SOAP get under 70ms/request for the most simple of requests. I haven't tested, but I'd guess PHP5 is closer to the Java numbers. For the next iteration of our release, I believe my project be moving to PHP5 and will enjoy the performance boost of the PHP5 ext/soap. There are a few development productivity related items that are missing there, namely in the automatic WSDL-to-code area. I know Davey has written this for Cerebral Cortex, but has not contributed it to PEAR. Feature wise, I think performance is key - which begs the question to should people/organizations look to PEAR to wrap the php5 extension with additional features, or just build more web services features into the extension. If the extension is the prefered direction going forward, then I would ask why not evaluate a relationship with the Apache Axis C ++ project or equivalent. There are a ton of emerging web services standards that are going to be needed, such as WS-coordination / WS-Transaction, WS-Policy, WS-Security, WS-Reliability, etc. It would be nice for PHP to follow the "glue another library in" model rather than constantly maintain parity with other frameworks/libraries by implementing specs. Partially implemented specs are dangerous as a project can get under way after some sanity testing that using a library works, and then they're 2/3rds finished and find an outage and code around it or define a new solution. My 2 cents, Al Baker On Thu, 2005-06-23 at 18:46 -0400, Chuck Hagenbuch wrote: > Quoting Justin Patrin <papercrane@gmail.com>: > > > A quick note from Chuck would even have been enough. > > I'm trying to let this go, but... what did you want me to write a note > about? All of the code was in CVS months before the press release. We > even released a new version of the package before the press release. > None of the commits hid what was going on - they described the bugs > that were being fixed. The new package version clearly describes all > the bugs that were fixed. All of it was done in the open before the > press release. Why does it matter who paid for the time spent doing > that? > > -chuck > > -- > "But she goes not abroad in search of monsters to destroy." - John > Quincy Adams >