jth at mikrobitti.fi
Tue Dec 23 09:10:48 UTC 2003
At 08:38 23.12.2003 +0000, you wrote:
>What's the particular advantage of SOAP (which, as I understand it, is an
>XML wrapper format for wrapping more XML), given that browsers mostly
>don't support it natively? I think Moz might, a little bit, but IE doesn't
>as far as I know.
SOAP itself is basically just a wrapper format, but related technologies
form a framework that allows fairly straightforward remote method calls
("Web Services") in a standard way. Don't confuse those two: it's like
judging WWW based on what HTTP is.
>Is it worth all the effort and added complexity that it would require?
>What is your "whole lot more"? :-)
SOAP beats most of the other possible external API solutions because of its
well-formalized and modern nature. This helps development enermously. Take
.net framework for example: You just type in a url for the soap service and
a developer tool generates a native language proxy class for the service
(so your code doesn't even really know it's a remote call). For browsers,
the situation isn't so great quite yet. Things are most likely getting
As for code complexity, we should examine before we slash it. If an
existing SOAP interface module for Perl suits our needs (as I'd expect to),
the result may turn out very clean and efficient.
I agree with Joel that SOAP is future, but don't have much ideas to help
here. Designing proper Web service interfaces takes work and thought, and I
haven't had the extra time (despite the fact that I've been wanting to
create an experimental "mostRecentBugs" SOAP service for quite some time -
I really could use that). Anyway, if you come up with something, I'll do my
best to help.
More information about the developers