>>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.
Going in that direction, yes, but only if your programmatic wrapping is
as expressive as the interface. libwww is not. Going in the other
direction (a network protocol based on a programmatic API), we end up
with a protocol that reflects the API rather than being efficient for
the application.
>>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.
It is only admirable if the resulting system works well. The goal of
building software is not to make it generic, but to make it usable.
Any genericity (a.k.a. mechanisms to improve reusability) must be
balanced against all the other ilities needed for a good system.
>>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?
A network-based API can be represented as an application-level wire
protocol. The same semantics can be represented by multiple wire protocols.
The reason I don't call it a wire protocol is because "what goes on the
wire" depends on many layers, and I'm only talking about one of them.
>>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.
HTTP GET has semantics. IIOP does not. The "Request" token only supplies
directionality so that the ORB can route it according to whether the ORB
itself is supposed to reply (e.g., "LocateRequest") or if it will be
interpreted by the object. The semantics are expressed by the combination
of object_key and operation, which (unlike HTTP) are object-specific.
While you can generate the same bits as an IIOP request without using
the same ORB, the bits themselves are defined by the CORBA API. You need
a UUID generated by an IDL compiler, a structured binary content that
mirrors that IDL operation's signature, and the definition of the reply
data type(s) according to the IDL specification. The semantics are thus
not defined by the network interface (IIOP), but by the object's IDL spec.
Whether this is a good thing or not depends on the application -- for
distributed objects it is a necessity, for the Web it isn't.
Why is this important? Because it differentiates a system where
network intermediaries can be effective agents from a system
where they can be, at most, routers.
This kind of difference is also seen in the interpretation of a message
as a unit or as a stream. HTTP allows the recipient or the sender to
decide that on their own. CORBA IDL doesn't even allow it (yet), but
even if it does get extended to support streams, both sides of the
communication will be tied to the same API.
....Roy