Re: The Two Way Web

Mark Baker wrote:
> >In any case, I _am_ discussing practical use of methods beyond GET,
> >PUT, and POST.  In the RPC/DO/ORB case, I'm talking about the method
> >names used in applications (IDLs).
> 
> I understand.  But I would argue that arbitrary RPC methods names have
> no place being methods over HTTP.  It's an entirely different problem.

really?  the strange thing here is that people are using
this already, and it seems to work extremely well.  may-
be they've missed your arguments?

> >GET and PUT make a lot of sense at the object and member field
> >accessor level (for Java folks: anywhere you'd use get*/set* methods)
> >but it doesn't make sense for all the other methods that applications
> >use.  A single POST operation would be _way_ too overloaded for
> >implementing a wide variety of methods.
> 
> I disagree.  GET and PUT are document/message granularity, not
> method/attribute granularity.  I would never use HTTP in that
> manner, since the number of network round trips would be
> prohibitive.

that's fine.  the question here is why you argue that nobody
else should be allowed to use it?

face it: XML-RPC (and the SOAP superset) solve existing problems,
are efficient enough for many real-life purposes, and are already
widely deployed.  I've implemented these protocols for Python,
and the mails I get give a very consistent message:

    1. people love it

    2. it works extremely well in cross-platform and
       cross-language environments

    3. people are smart enough to figure out when
       to use it, and when to avoid it.

(maybe you should give it a try?  you can find the Python version
here: http://www.pythonware.com/products/xmlrpc )

> So, you're left with designing your own protocol if you've really
> got a problem that can't reasonably be broken down to documents.
> Or if you can break it down, use HTTP.  But please, no RPC.

too late.  real people are using this for real applications.

pissing on the parade won't change that.

</F>

Received on Monday, 13 March 2000 07:03:07 UTC