libraries

[Andrew Tridgell]

Luke wrote:
> i agree.  i have wanted something like this to happen for a long time,
> ever since i started on the ntdom code.

sure, but it won't happen instantly. It takes time to disentangle the
code so that each utility doesn't depend on non-generic code from the
other. I've been doing this for quite a while and the 2.0 tree is
certainly a heck of a lot better than the 1.9.18 tree in that regard,
but there are still some weaknesses. 

There isn't a magic bullet that will solve this, not even "making
shared libraries" or using a tool like libtool. What needs to be done
is some good coding and layering design. 

This particular discussion started with Richard worrying about having
to have SSL libraries linked to everything. If you think about _why_
that is currently needed then you will understand why it is a big job
to fix. 

The SSL libs are needed everywhere because we have at a fairly low
level library routines that handle sockets (in util_sock.c). Those
routines need to be modified for SSL support which means they need to
call SSL routines. So anything that links to that library needs to
also link to the SSL routines even though they will never call them.

To fix this we would need to split off our communications routines
from the rest of our library routines. So we add a COMMS_OBJ in
Makefile.in and put the comms code in separate files. Then we need to
make sure that none of the non-comms library code calls any of the
comms code. That may sound easy, but it isn't. Think about our
password code that needs to open sockets to password servers. Think
about our name resolution code that needs to talk to WINS servers. All
that needs resolving.

That can all be done (it is maybe a days work) but is it worth it?
That isn't clear at all. 

It is worth it if it makes the code clearer and more easily
maintained. Modularity is not an end in itself. If making some part of
Samba more modular makes our jobs easier by making the code easier to
maintain or allows us to do something useful that we couldn't do
before then great, if it doesn't then we need to ask why we are doing
it.

An example of bad modularity is the frequently raised idea of
splitting the rpc code into a separate daemon. Yes, it makes the code
more modular, but it also will make it vasty more complex, bigger and
harder to debug. As no one has yet pointed out an advantage (apart from
modularity and "it's what NT does") I don't see why we should do it.

An example of good modularity is the client code as other apps want to
use it which means we get something we haven't had before. I've been
trying to make the two layers in the client code (libsmb/*.c and
smbw/*.c) more modular for exactly that reason.

So muster your arguments for modularity of specific components, but
please think in terms of real advantages.

Cheers, Tridge