Re: SWM, 28, ISO single generic event API. Flexible, will

Mark Baker (distobj@acm.org)
Wed, 06 May 1998 21:32:39 -0400


Oooo nooo, bits.

At 02:09 AM 6/5/98 -0700, Roy T. Fielding wrote:
>A network-based API is an interface that exists on the network itself:
>a gateway through which different applications can communicate by
>restricting themselves to a set of well-known semantics (syntax too,
>but that's the easy part).

So, if we decide to wrap this interface programmatically (ala libwww), have
we lost any information? I don't think so. They're both equally
expressive, and express the same info.

>A library-based API does a lot more for the programmer, but in doing so
>creates a great deal more complexity and baggage than is needed by any
>one system, is less portable in a heterogeneous network, and always
>results in genericity being preferred over performance. As a side-effect,
>it also leads to lazy development (blaming the API code for everything)
>and failure to account for non-cooperative behavior by other parties
>in the communication.

Genericity derives from the explicit attempt to steer clear of the "build
your own transport protocol" (or whatever) syndrome. An admiral goal.

>A network-based API does not place any restrictions on the application
>code aside from the need to read/write to the network, but does place
>much larger restrictions on the set of semantics that can be effectively
>communicated across the interface. On the plus side, performance is only
>bounded by the protocol design and not by any particular implementation
>of that design.

So what's the difference between a "network-based API" and a "wire
protocol"? Human-parsable vs. not?

>Mind you, there are various layers involved here -- systems like the Web
>use one library API (sockets) in order to access several network-based
>APIs (e.g., HTTP and FTP), but the socket API itself is below the
>application-layer. Likewise, libwww is an interesting cross-breed
>in that it is a library-based API for accessing a network-based API, and
>thus provides reusable code without the assumption that the other
>communicating applications are using libwww as well.

And similarly, if I'm a CORBA object, you can make requests of me via IIOP.
But I don't care what library API you're programmed to. I only care that
you're spitting out IIOP. It could be through RMI, Tcl, Python, etc..

HTTP has "GET". IIOP has "Request" tokenized as 0x00.

>Contrast this with
>CORBA, which only allows communication via an ORB,

Not true (as mentioned in the previous paragraph). Just speak IIOP.

>thereby leading IIOP
>to assume too much about what the parties are communicating.

It only assumes point-to-point request/response.

MB

--
Mark Baker.               CTO, Beduin Communications Corp
Ottawa, Ontario, CANADA             http://www.beduin.com