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
> 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.
More information about the samba-technical
mailing list