All the Perl that's Practical to Extract and Report

Navigation

use Perl Log In

acme (189)

acme (email not shown publicly)http://www.astray.com/Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.

Arrrggggh, PAIN!

If you were at the lightning talks at OSCON, you would know that the
website architecture used for the new work project Vx is entirely based
upon web services. Yup, SOAP baby. All of it. This is very cool, but
until now we were completely deadline oriented. Last week I had a
little time to think about writing standalone SOAP clients to the
photo album website based upon it. Compare and contrast two days:

Friday: Finally get some time to work on standalone SOAP clients. I
study the interface and knock up a standalone command-line SOAP client
in Perl in about 100 lines of code. You pass it the image you want to
upload and it uploads it via web services (instead of say, web browser
upload). Cool:

% bin/upload ~/sheep.jpg
Uploaded/home/acme/sheep.jpg.

I thought a graphical tool would be nice, so I grabbed the office copy
of "Learning Perl/Tk" and got a quick Tk app together in
about half an hour (it even has a progress bar!). Tk isn't the
prettiest thing, but it does the job.

My next step was Wx (Wx/GTK to be more precise). The docs for WxPerl
are somewhat lacking, but I dug around in the main WxWindows
distribution and eventually got a very nice Wx app together. It
looks a lot more polished: the file selector is better, and it has a
really good progress dialog.

So that was Friday. I felt good, had built three programs and I
loved SOAP. Monday was different. I tried to build apps in languages
other than Perl to do the same thing. Granted, I'm a Perl programmer,
but I thought it'd be easy.

I start off looking at Java. I download the Apache SOAP toolkit and
it requires the Java mail API for reasons I fail to understand
(but I don't want to use that!) so I skip and head over to The Mind
Electric's Glue, which requires WSDL to do anything. We don't have
a WSDL file yet. Next I try Python. I haven't done much Python
programming, and I try SOAP.py and ZSI. The former fails most of its
remote tests and the latter gives a weird error when connecting
to our SOAP::Lite server. Arrrgggh. I though the point about SOAP
was that it was SIMPLE. Apparently not. I've given up. I'll let
Java and Python programmers do this instead. The pain... the pain...

[Oops, almost forgot] I also completely failed to install PerlTk and WxMac under Mac OS X. Oh, and Camelbones was way too scary:-(

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

this puts paid to some of the FUD about Java's stronger and 'native' xml support.

That's not a fair assessment of what Leon described. Apache-SOAP had this dependency on mail handling, because as we all know, email is a key component in web services (and I'm only half joking).

In reality, the problem is with SOAP. It's a very big spec, difficult to implement fully (and properly!), so there are lots of interoperability problems. Had Vx been coded with Apache-SOAP from the start (in Java), then I sus

Right, Perl is just too dynamic for WSDL really. That's why Pierre thought up the very clever WSDL::Generator, so all we need to do is figure out why it doesn't work with 5.8 and then run the test suite with it installed. With any luck, a fully-specced WSDL will fall out. I'll try again when we have this...

Well so far I just followed the CamelBones tutorials, and then learned extra bits from the Apple docs (which are extensive). I've now also bought a Cocoa programming book, so that should also help quite a bit.