dce/rpc "client" api

[Cole, Timothy D.]

> -----Original Message-----
> From:	Steve Langasek [SMTP:vorlon at netexpress.net]
> Sent:	Tuesday, August 22, 2000 9:49
> To:	Luke Kenneth Casson Leighton
> Cc:	Andrew Tridgell; samba-technical at samba.org
> Subject:	Re: dce/rpc "client" api
> 
> 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.
> 
	I believe what Luke's arguing here is that a socket interface that's
pretty much limited to pushing around DCE/RPC PDUs is going to be a lot more
stable (in terms of interface compatibility) than a shared library interface
where you have to worry about symbol dependencies.

	I don't think the shared library interface would be unmanagable by
any means, but speaking from personal experience it's going to be a lot
harder to keep things compatible across revisions unless you stick to a
strict "no globals" policy.

> 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.
> 
	This is just my personal experience again, but exposing variables as
part of library interfaces at all seems to me to be just asking for
maintainence headaches.  I don't think Tridge was planning on exposing many
globals in the interface anyway, though, from what he was saying.

> 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.
> 
	I don't really think it is.  This is just one facet of the whole
pro/con dealio.  Arguments could also be made about the normal
in-process/out-of-process tradoffs, etc, too.  The DCE/RPC approach does
also buy you a lot of flexibility, for example.