Subject: Re: SA daemon

From: Erik Guttman <[email-masked]>
Date: Wed, 9 May 2001 09:41:21 +0-200

Sean, Jim,

My take on this follows.

Sean Kelly <[email-masked]> wrote:
>>	I don't believe that the mechanism allowing
>>the local processes to register with the SA daemon
>>is specified in a RFC, but it appears to be implemented 
>>in both the OpenSLP and Sun SLP through the SA daemon 
>>supporting SvrReg, SvrDeReg, SvrAck on connections 
>>from the local host. This is a logical approach since
>>only one process can bind to the SRVLOC port.
>>
>>	My question is interoperability.

Jim Kempf <[email-masked]> wrote:
>I suppose we could look into standardizing the intra-machine protocol if
>there was enough interest, but without a major customer requesting the
>change, it is unlikely that any change will be made in Solaris SLP at
>this point.

The IETF focusses on interoperability on the wire.

Application portability, that is binary compatibility of
applications to libraries sharing the same API, is not an
area of focus for the IETF.  Some APIs have been published
by the IETF - for service to the community, but these are
rarely standardized.  The SLP API is an example of an 
'informational' status API.  Aside from the GSSAPI and LDAP
APIs I do not know of any other standards track APIs published
by the IETF.

The kind of interoperability being discussed is entirely 
different.  How do binary components, within a system, 
communicate?  This standardization occurs within desktop
environments and operating systems - for example Gnome
Bonobo components, OLE objects or drivers within an OS.  
Even there, things get dicey.  Drivers and libraries 
export a few very simple, standard features which can be 
accessed through common administration applications,
controlled by scripts, etc.  But the specialized behavior
of the libraries (all optimizations, differentiators, 
and so on) require vendor specific application utilities.
That is why, for instance, when you buy a printer for
Windows, it often comes with its own print monitor and 
job control utility (which makes use of bells and whistles
added to the standard printer driver).

I do not think this is a fruitful direction for us to 
pursue.  I'll send another email with ideas about where
I suggest directions for work on interoperability.

Erik