Nelson Minar: If you're comfortable parsing XML, you're
comfortable parsing doc/lit SOAP. But SOAP also offers the
possibility of automatic data bindings (no parsing required) and
WSDL (service description). Alas, those technologies still don't
work so well in Perl, Python, or PHP where doc/lit support is weak.
It does work pretty well in Java and .NET.
Automatic data bindings is not as important in dynamically typed
languages. Parsing XML in PHP is pretty easy with things like
together, this leads to the conclusion that a toolkit approach may
not be required.
At the moment, in PHP if you want to do an HTTP POST, you need
to use functions like
A built-in function that made it easier to do a arbitrary POST
would be useful in its own right.
An almost built-in set of functions for PHP is CURL.
The real problem here is lack of support for Doc/Lit in PEAR::SOAP. There is some in there, it's just not very complete or documented. That's what we should be concentrating on, not re-inventing it. I don't know if the PHP5 SOAP module is any better, but a quick look at the docs suggests not.
The same goes for Perl and Python. We've got to get away from fixing the toolkits and get on to writing applications.
Think there's something inherent about the dynamic languages (or their builders) when it comes to "going the distance". Past the "80% works" mark rarely seems to happen which means more obscure parts of specs don't get implemented. Perhaps that's simply a result of most working in free time.
With Curl the problem is it's an optional extension for PHP. Also the API in PHP isn't exactly sense making as an HTTP client, IMO - would be nice to see something modeled after XmlHttpRequest.
Puzzled why the new PHP SOAP extension didn't expose an HTTP client somewhere. Even more puzzled as to why it seems to be a SOAP implementation from scratch, vs. using say OpenSOAP ([link]) which seems fairly mature. Also strange is it looks like none of Perl, Python or Ruby seem to be using OpenSOAP, even though it uses libxml2 in turn. Could be I'm missing something - haven't looked that hard.
In the meantime, if you are unhappy about the lack of support for a library which has little documentation and even less visible activity in the past two years, perhaps you could lend a hand by writing a wrapper library, documenting it, testing it, and packaging it for distribution on various popular platforms.
"In the meantime, if you are unhappy about the lack of support for a library which has little documentation and even less visible activity in the past two years"
Do you mean OpenSOAP? Seems to be still pretty active although there doesn't seem to be a public CVS repository (which may answer the question as to why no ones using it).
"perhaps you could lend a hand by writing a wrapper library, documenting it, testing it, and packaging it for distribution on various popular platforms."
Fair point ;) In the case of PHP, seems like a smarter approach that building from scratch.
Regarding that 80% remark, what was on my mind was again PHP. Even thinking about XML-RPC implementations or PHP-based HTTP clients, there's a whole load of projects which reach that mark then seem to grind to a halt. I'm one of the guilty.
That said perhaps what Sam's looking for in PHP is PEAR::HTTP_Request which makes a quick POST fairly easy;