dce/rpc "client" api
vorlon at netexpress.net
Tue Aug 22 13:49:25 GMT 2000
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.
> 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?
More information about the samba-technical