2010/3/30 Mark McLoughlin <markmc(a)redhat.com>:
Hi Jérôme,
You got the first post, congrats! :)
Thanks,
On Tue, 2010-03-30 at 17:56 +0200, Jérôme Fenal wrote:
> for this choice, what are the expected scripting/dynamic languages
> APIs to be supported ?
>
> For Satellite/Spacewalk, lots of users are Perl users, and proposing
> SOAP solely could left those users (including myself) behind, as
> SOAP::Lite is not really on par with what Java can offer.
>
> Furthermore, current competition users already have a Perl API, which
> could leverage these skills as well with RHEV-M.
>
> I don't know what Python or Ruby (besides JRuby) can offer here, but
> these should be considered as well when defining the API access
> protocol.
One of the advantages we were assuming with SOAP was that there would be
good SOAP client support (i.e. automatic client binding generation) in
most languages, so I'm surprised to hear it can be a pain in Perl ...
The python SOAP library I've played with is Suds:
https://fedorahosted.org/suds/
The really nice thing about that is you just point it at the WSDL
describing the service and away you go. See the simple example in our
tree:
http://bit.ly/96WD6T
Is this not something similar for Perl?
http://soap-wsdl.sourceforge.net/
Did not know about that one, worth to test it, once I explored how to
get the mock bean installed (for the moment, not enough hardware yet
at home to install a full RHEV-M).
My last experience with SOAP & Perl was back in 2005, and left me with
a bad taste. However, this was with SOAP::Lite 0.60, against an Axis
1.0 (1.1 ?) implementation, so this may also (on both sides) explain
why it went wrong at that time.
In particular, if my meory serves well, it had to do with the kind of
XML I got in the answers. SOAP::Lite knew about <node parm="value" />,
when Axis returned <node>value</node> or something approaching.
Anyway, you get the idea.
It would be worth to test a recent SOAP::Lite this as well, but really
wanted to set the case for Perl (and other dynamic languages where a
valid SOAP implement may not exist), and where in my view REST was
easier to implement. But I can prove to be wrong here. :)
Regards,
J.
--
Jérôme Fenal - jfenal AT
gmail.com -
http://fenal.org/
Paris.pm -
http://paris.mongueurs.net/