Re: Web RPCs Considered Harmful

Dick Brooks wrote:

> Dave,
> - the spectrum of processing modes people desire
>    (one-way - a.k.a. simplex communications, synchronous request/response -
> a.k.a. RPC, asynchronous messaging)
> - support for multiple transports (HTTP, SMTP, FTP)
> - secure operation
> - an easy to program, simple service interface (API and event notification
> system)
> - scalability
> - reliability
> - manageability
> - privacy, authentication, integrity and non-repudiation
> - support for all types of data representation (XML, X12, JPEG, whatever)

IMHO should formats as JPEG not be part of a RPC because RPC is interprocess
invokation of remote functionality.

>
> - flexibility (let the implementers choose the degree to which they support
> all of the functions available in the  protocol)

This a daunting task of supporting all above features and frankly most of them
have already been specified/implemented by other standards such OMG Corba and
industry standards such as MS DCOM.

This begs the question, what should the scope be for an Internet RPC/OO stanard?

Should the goal be to support all different messaging/protocol concepts
currently in
use or should the goals be more modest ?

And a comment on performance, XML encoded messages will always be considered
as highly inefficient compared to binary encoded messages.  I have created
FastML
(binary ml) for research purposes and have measured up 30x times faster parsing
speed compared to XML parser Expat (C language parser).
This probably means that for realtime/high performance users,  XML based
messages
is not an option.


/anders
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
/  Financial Toolsmiths AB            /
/  Anders W. Tell                     /
/ WWW:  <http://www.toolsmiths.se>    /
/ XIOP: <http://xiop.sourceforge.net> /
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Received on Saturday, 13 May 2000 15:57:05 UTC