dce/rpc "client" api

[Steve Langasek]

On Tue, 22 Aug 2000, Luke Kenneth Casson Leighton wrote:

> > If the shared library used that variable and you remove it then the
> > shared library will no longer load. Bad luck.

> exactly.

> this in and of itself is a good reason for not promoting the .so system as
> a viable substitute for the daemon architecture, which _does_ solve the
> issue that you surmise that the .so system will solve, namely that it will
> be possible to mix-and-match services from different development branches.

Luke, it seems to me that this is a non-issue.  *Any* time you change the
interface between two pieces of code, you're going to break something, no
matter if that interface is a Unix socket or a dlopen() call.  If you're
worried about referencing global variables that are going to disappear, then
you carefully choose the variables that are legal and included as part of the
library interface; you don't throw the whole idea out.  Is this anything more
or less than what you'd have to do when defining a socket interface?  I'm not
qualified to judge whether a .so or a daemon dce/rpc implementation is better,
I just don't think this should be the deciding factor.

But then, perhaps I don't understand as clearly as I should.  What global
variables do you foresee a shared-lib implementation of DCE/RPC services
needing to make use of?

Steve Langasek
postmodern programmer