dce/rpc "client" api
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Tue Aug 22 15:27:01 GMT 2000
> -----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
> > a viable substitute for the daemon architecture, which _does_ solve the
> > issue that you surmise that the .so system will solve, namely that it
> > be possible to mix-and-match services from different development
> 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,
> you carefully choose the variables that are legal and included as part of
> 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
> qualified to judge whether a .so or a daemon dce/rpc implementation is
> 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.
More information about the samba-technical