Hung Jung Lu wrote:
> >From: Ender <[EMAIL PROTECTED]>
> >...
> Thanks for the comments. I'll reply other points in a few more days.

cool, i've been waiting for this discussion:)

> >as for distributed technologies, while xml-rpc is useful and simple its
> >not useful (IMO) for enterprise programming, its too basic.
> This maybe true. However, HTML is also basic and simple, but exactly because
> of its simplicity, it became widely accepted and used. On the opposite end
> is CORBA: because it's so complicated, there is no vendor out there that can
> possibly implement all its features. Trading powerful features for a wider
> acceptance at times does work.

don't forget marketing, behold windows.

CORBA is complicated but its also more widely deployed in the enterprise
because this problem domain needs the additional feature set. 

my comments regarding xml-rpc are targeted towards enterprise
implementations. if all you need is simple rpc, than xml-rpc will
provide 80% functionality of soap at 20% of the complexity (not my
numbers) and i recommend to anyone to use xml-rpc. but if you need
actual cross-platform object access/transport, than it just won't cut it
and then you need the additional functonality of soap.

also back to the marketing hype, if something isn't supported than it
tends to wither away into a niche. while xml-rpc is used in the trenches
for lots of stuff, SOAP is supported by lots of major software
developers (ibm and ms come to mind) and it will become the future
standard supported by interoable products (in many ways it already has). 
> SOAP is showing symptoms of becoming complicated. And that's a bad sign. See
> Fredrik Lundh's implementation comment for Python SOAP at

> >Profile
> >Posted Jun 08, 2000
> >
> >SOAP 1.1 is a highly modular and rather complicated standard. Supporting
> >every little nook and cranny is huge task, and since the specification is
> >still a moving target, we've decided to do this implementation step by
> >step.
> OK. Even the guru describes SOAP as "rather complicated", what then for the
> novices? 

implementing a standard and using a standard are different things. do
you need to understand how a db works to query it?

do you really need to understand how xmlrpc works when you do something
like this?

print xmlrpcServer.objectIds()

i think that as long as the library implementors create a clean
interface to the system than the novice should be able to use the system
without as a blackbox.

>I personally went through the SOAP protocol spec today and I had to
> agree it's "rather complicated". SOAP is going down the path of CORBA all
> over again. It's becoming COAP (Complicated Object Access Protocol). If not
> because Microsoft is behind it, I'd dump SOAP right away. Due to its
> simplicity, I'd say XML-RPC is here to stay, SOAP or no SOAP. It's
> unfortunate that the twin brothers have to fare good-bye, but at the same
> time I am glad that XML-RPC split off to remain simple. Future servers will
> have to handle both: more work, but that's fate.

i agree with /F description of SOAP, but i have a different guru.

Dave Winer is the/a writer of the specs for of XML-RPC and SOAP. a bit
dated link.

I agree that there is a place for both protocols, (right tool for the
right job), and that zope should support both. although how is another
can of worms, since i don't think people want the same xml-rpc style
automatic opening of your entire site that currently happens with zope. 

incidentally some other useful links

# distributed lightweight protocols

# alternative python soap-rpc lib



Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to