On Thu, 2002-05-23 at 23:38, Markus Wolff wrote: > Stig S. Bakken said: > > PHP already has SOAP support bundled in the xmlrpc extension, which > > is built upon the xmlrpc-epi library that we bundle. Why can't > > people improve that instead of re-inventing more wheels in all > > shapes and sizes? When we bundle a library, we should use it. > > > > - Stig > > Unfortunately, not all (in fact, very few) providers install that > extension - as well as they don´t install many other useful but not-so- > common extensions. They´ll keep it this way unless enough people ask > for it. But as long as only few people know these extensions exist (in > part because so few providers install them), not enough people will > ask for them. > > The best thinkable solutions would be: > a) Bundle a library like PEAR::SOAP with PHP that is modified in a > way that it automatically detects if the xmlrpc-epi extension is > installed. If so, PEAR::SOAP only acts as a wrapper class around > the calls to the extension. Else, it uses its own, slower > PHP routines. > b) Integrate xmlrpc-epi support as a standard extension that is > installed by default.
I think this is a good approach. It's the same thing we did with PEAR DB: make a good API first. The only thing that worries me with the PEAR SOAP and PEAR XML_RPC APIs is that they use objects for everything, even a boolean is represented by a freaking object, both slow and very cumbersome. The beauty of xmlrpc-epi is that you deal with native PHP types (with some extra hacks for binary and date strings). This means exporting existing functions through xmlrpc is as easy as can be. - Stig -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
