[Python-Dev] Leading with XML-RPC

David Ascher DavidA@ActiveState.com
Tue, 10 Jul 2001 13:55:30 -0700


"Eric S. Raymond" wrote:
> 
> Skip Montanaro <skip@pobox.com>:
> > In my opinion supporting both XML-RPC and SOAP in the core library would be
> > a good thing.  It's sort of like PIL supporting both GIF and JPEG image
> > files.  Both have their uses.
> 
> +1.  I think supporting XML-RPC is close to being a no-brainer at this point.
> What to do about SOAP is a less trivial question.

FYI: We use a slightly doctored version of /F's xmlrpclib, IIRC, as well
as a slightly doctored version of /F's SOAP library.

I'm +1 on adding both of those to the library, so that we can get rid of
these various 'slight doctorings' =).

I'm +1 on adding good DAV support as well, although I think that that
will have to be through the addition of Neon.  Greg's davlib.py isn't
really industrial-strength, from what Greg tells me (e.g. no support for
authentication), and I don't think Greg is spending much time on it. 
Alas, Neon is C code, and still in flux.  Greg will speak up whenever he
resurfaces =).  If we had 'stubs' like Tcl, we could ship a Neon wrapper
w/o Neon, which would be good.  But we don't. =)

Documentation is probably the bigger problem, though, as usual.

However, as much as I like XML-RPC and SOAP and WebDAV, I don't know
that adding support for these protocols will have much impact on the
folks that are being exposed to the .NET story.  SOAP, especially, works
well with .NET, rather than competing with it.  I don't think anyone
wants to setup an "XML-RPC vs. SOAP" war, that'd be pretty pointless.

-- David Ascher

As a PS, I'm all for adding support for these protocols to Python, but I
don't see the relationship to 'turning up the heat on Microsoft'.  I'd
think there would be better ways of doing so, should you be so inclined
=).  [After reading Dave's piece on Mono, I understand why he thinks
that would 'work' -- but now I think he underestimates the scope and
depth of .NET -- adding interop through SOAP does not make the
alternatives competitive -- see the discussion on language-dev].