>I'm think that's what we were calling for, but I'm not really sure I
>completely understand Roy's point. What's the diff between a "network API"
>and a "programming API"?
Hmmm, bad terminology I guess. Instead of "network API", let's call
it a "network-based API", and we can call the other a "library-based API"
for lack of a better word.
A library-based API provides a set of code entry points and associated
symbol/parameter sets so that a programmer can use someone else's code
to do the dirty work of maintaining the actual interface between
like systems, provided that the programmer obeys the architectural
and language restrictions that come with that code. The assumption is
that all sides of the communication use the same API, and therefore the
internals of the interface are only important to the API developer and
not the application developer.
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).
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.
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.
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. Contrast this with
CORBA, which only allows communication via an ORB, thereby leading IIOP
to assume too much about what the parties are communicating.
On a related note, does anyone know where I can get a readable (Word or PS)
copy of the "real DCOM spec, as implemented". I've got
draft-brown-dcom-v1-spec-03.txt, but the text conversion sucks.
Likewise, the ridiculous font override on
http://www.microsoft.com/oledev/olecom/title.htm
makes me snowblind.
....Roy