Jon Udell: For me, C# was easier in one way and harder in another. It was easier because Visual Studio .NET made consumption of the WSDL APIs frictionless. I'm curious as to why this isn't true for, say, Python. There are existing libraries that purport to do this. Is the issue awareness, license, deployment, functionality?
If there are issues, and interest expressed by Groove developers and/or users in collaboration on flattening them, then I would be willing to contribute.
I can understand this. VisualStudio is very, very slick. In all the language wars, few people mention the importance of tools.
MS has been working on VS for so long, and things are so well integrated, it is hard to compete with. As long as you don't look at the code it generates.
However, Emacs and Notepad remain as popular as ever.
It seems to me that Python has the right balance of structure and the ability to dynamic bindings so as to be ideal for the task that Jon set out to do, yet Jon seems to have found it wanting. This peaks my curiousity.
As mentioned in the article, the GWS-SDK provides C# and Perl starting points. Being lazy, I went that route, and along the way I noticed that some extra Perl code had been written to enable SOAP::Lite to do doc/literal serialization, and to inject SOAP headers into the messages.
I haven't yet tried Python, but I'm guessing some intervention might be needed there -- as, somebody mentioned somewhere today -- it would probably also be needed for Frontier.
Python's certainly easy if you are intimate with the SOAP interface. I find it's often a question of what you know. For instance, if my goal is to talk to a SOAP interface that I haven't used, there's no question that intellisense and all those tools in vs.net are gonna help me make sense of that interface quickly. However, if I'm writing code against a SOAP interface that I wrote, then I can bang it out in python or SOAP::Lite despite the fact that I barely know enough perl or python to hurt myself. That said, with C# I find that my inferences about the APIs are correct much more often than with java. I've seen this when writing mono code where I don't have all of the vs.net tools at my disposal. I still manage to guess the APIs correctly most of the time. That probably has a lot to do with my having written a fair bit of MFC.
Well one reason may be that the libraries you have linked to do not work. At least not the PHP versions. Additionally the example WSDL document that page links to is not working either. That particular toolset, which, at least at first glance, appears VERY simple to use, is non-functional.
I gave the PEAR/SOAP libraries a spin only to find several bugs there as well. Thankfully, in this case, the bugs aren't horrible and the author has responded stating that he will apply my corrections.