Re: Web RPCs Considered Harmful

"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
significance.

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

  -- Ken

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