So to answer your points:

bikeNomad got so many votes because he gave a good answer.

SOAP is the right answer

I can't believe you can implement a XML client-server combo in less lines than I can do one with SOAPlite. If you can, post it here and I promise I'll spend the next month upvoting all of your posts.

If you also manage to make it interoperable with MS COMs, implement C and Python libraries, and provide a abstract transport layer that allows communication over TCP/IP, email and other goodies like that., I'll drop at your feet.

Until then, check out SOAPlite.

____________________
Jeremy
I didn't believe in evil until I dated it.

Well, I certainly don't need all of that. That's my point. I just want a gpg wrapper around some xml data that I trade back and forth. I've got apache running anyway, and the client stuff is going to be a java application.

So, none of the features you've listed here actually help me. I think I understand now in fact. You're imagining something quite a bit more complicated than I am. So, minus all these features you've listed, I'm bettin' my cute little XML::Parser "server" (CGI) was quite a bit faster to code, since I didn't have to learn anything.

You guys have me convinced though... I'm readin' more and more about SOAP, and I'll be sittin around thinkin' of a project to use it on. This isn't the one, but there'll be one soon! It's really neat... I think.

mitd's post 99566 way down at the bottom was the real clincher here.

Although, as jepri points out, bikeNomad is a good answer the leap that he ( jepri ) makes from good to right is at best subjective and at worse premature.

It is very true that SOAP::Lite is a great implementation of SOAP but it may be premature if you haven't first researched SOAP itself.

Here is a list of URL's that may help:

• A Brief History of SOAP

  Don Box's excellent history of SOAP

• Everything XML-RPC

  This XMLRPC.ORG a great resource but read Dan's piece first to understand the SOAP - XML RPC relationship.

• SOAP v1.2 Working Draft

  THE SPEC. Remember this is a W3 Working Draft therefore it should be considered a moving target. The XML Protocol Working Group (WG), which is part of the XML Protocol Activity owns it and they are difficult to ignore

• ESR seems to like it

  Eric Raymond certainly voices my feelings on the whole subject of Remote Procedure Call interfaces and how SOAP/XML-RPC fit in.

Hope this helps.

mitd-Made in the Dark
'My favourite colour appears to be grey.'

Sure it's subjective, but I'm having trouble thinking of circumstances where SOAP is not a good idea. the only one I can really think of is low bandwidth/low memory situations, where the overheads for HTTP and the processing time for the transport stuff becomes significant.

So if you are implementing a XML RPC server on your Palm I agree SOAP is wrong. Other than that, I can't really see a reason not to use it.

OK, one just occured - doing callbacks is not the easiest trick, but is trivial to work around.

____________________
Jeremy
I didn't believe in evil until I dated it.

Nerd Critters!

My point is that you are correct! But jettero just isn't in the space to accept you opinion yet. To get there he needs to understand what SOAP can do for him. Then he can accept SOAP::Lite as a great perlish way to enter the fray.

mitd-Made in the Dark
'My favourite colour appears to be grey.'