🚀 go-pugleaf

In article <MORSE.91Feb12152547@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes:
>[stuff deleted]
>Why, then, is there no light-weight mechanism for applications to
>communicate with other applications that might happen to be located on
>the same system? If I don't want my application to know where it is,
>or where the applications that it communicates with are, shouldn't
>that be addressed (no pun intended) by the stack? Surely, I shouldn't
>be reasonably expected to use X.25, or FDDI, for IPC. (Something
>related to this is the lack of a decent performing name service. X.500
>is clearly not a great name service for an RPC.)
>
>Am I all wet here, and it really isn't the intention of the OSI that
>application entities might reside on the same system? Perhaps I'm just
>impatient, and these issues will be addressed by the ODP work?

My understanding of the intention of OSI (at least a couple of years
ago) is to standardize Intersystem communication.  Any intrasystem
issues were considered private to that system and not to be defined by
OSI. This includes layer boundry interfaces.  It is not inconsistent
for a system to provide a local IPC mechanism which appears the same as
the remote IPC mechanism to an application.  IMHO, that is the right
thing to do.  The local mechanisms have not been within the scope of
OSI definition.  On the other hand, other groups have been working on
standardizing local system interfaces and API's, ex. TLI for unix. 
This work may result in the 'defacto' standards for local 'light
weight' mechanisms that you are looking for.