W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

Re: Web RPCs Considered Harmful

From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 16 May 2000 09:39:21 -0500
To: <xml-dist-app@w3.org>
Message-ID: <x5aehqftk6.fsf@bitsko.slc.ut.us>
"David Boreham" <david_list@boreham.org> writes:

> > I don't see obfuscation as being the problem. I'm more concerned about RPC
> > interfaces which are fully published, but can't map onto other
> > implementations than the initial one. Consider an interface that requires
> > every object to be manipulated to have some unique numeric ID; a system
> > that doesn't assign numeric IDs to its objects is going to need massive
> > kludges to implement such an interface.
> Clearly there needs to be a standardization process for each "RPC"
> interface which is to be widely used. Perhaps a useful analogy is
> the SNMP MIB development process, or the LDAP control specification
> process.
> In the context of this thread, I am still entirely not convinced
> that the "RPC-ishness" of the encoding protocol makes one little bit
> of difference here.

If by context of this thread you mean that having standardized APIs,
implemented over RPC-ish protocols is no different than standardized
APIs built in as protocol semantics, then I would probably agree.

That wasn't the issue issue that started the thread though.  The issue
that started this was the active promotion of non-standard APIs and
multiple implementations of those APIs.  At this point, the currently
expected (intended, even, by some) usage of RPC-ish protocols is for
one-off implementations.  The RPC-ish protocols are intended to be an
enabling tool for developers of all sizes to promote their
applications using a standard, decidedly RPC-ish, protocol.  In _that_
context, the _usage_ of RPC-ish encoding protocols is of utmost

Standards bodies must take into account expected and intended uses of
the standards they recommend as part of the standards development

  -- Ken
Received on Tuesday, 16 May 2000 10:33:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:27 UTC