|
From: Skip M. <sk...@po...> - 2001-09-18 18:53:49
|
(apologies if you receive this multiple times - i've been having mail
problems - originally sent 12 Sep 2001 13:50:11)
(I am still having trouble sending to this list. I originally posted this
note on September 7th but haven't seen it turn up expect as a mail bounce.
In some sense this is simply a test. My apologies if you're seeing this
message twice.)
Kevin> At some point we are going to support XML, at least for
Kevin> import/export and possibly the resource format. It will certainly
Kevin> be used for any XML-RPC or SOAP connectivity, which is probably
Kevin> how PythonCard apps are going to talk to the rest of the world in
Kevin> a standard way.
I think there is an important distinction to make between SOAP and XML-RPC
on the one hand, and things like storing Pythoncard resource files in XML on
the other hand. From the programmer's standpoint, SOAP and XML-RPC are just
RPC protocols. I've been using XML-RPC for about three years now, and the
only time I've ever looked at the raw XML was when I was mucking about in
the xmlrpclib.py implementation and screwed something up. My clients and
servers pass tens of thousands of messages back and forth every day and I
never pay any attention to the XML. In other words, from the standpoint of
Pythoncard users or developers, SOAP and XML-RPC might as well be using
paper tapes encoded in Morse code, tied to the legs of carrier pigeons to
get the data back and forth. There are issues of bandwidth usage and the
costs to marshal and unmarshal data with SOAP and XML-RPC, but they aren't
insurmountable, and really only come into play if you are transferring lots
of data. (They would often be problems with other RPC encodings as well.)
The October issue of WebTechniques magazine (not available online until
September 12) has an article about SOAP. It posts the obligatory XML for a
simple request and response. No code was posted (that I recall) showing how
to make a SOAP call from Perl or Python. In my mind, by dwelling on the
transport encoding the article completely misses the point of using SOAP (or
XML-RPC or ORBit or Fnorb or ...), which is that for the application
programmer, they make RPC programming drop dead easy.
All the pros and cons of XML will only come into play when you have to
invent an XML encoding for, say, Pythoncard resource data. I would only
worry about most of the Pros and Cons listed in the Zapthink article in that
light.
All that said, the Zapthink article does look like a good contrast of the
pros and cons of XML.
--
Skip Montanaro (sk...@po...)
http://www.mojam.com/
http://www.musi-cal.com/
|