libraries

[Luke Kenneth Casson Leighton]

andrew throws some sense into this thread :)

> 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.

ok, tangental tack (take rpc code as a specific example).

can anyone else think of good reasons to split the rpc code into a
separate daemon (actually, potentially several daemons: one endport mapper
on port 135, then one daemon per rpc pipe to which the endport mapper will
refer each connection)

i can think of 2:

1) it's the way dce/rpc opengroup does it.  if it's good enough for them
it's good enough for me.  just please don't put in a thread library,
PLEEEAASE!

2) samba source code, at 125,000 lines of code, is pretty daunting.
40,000 of those are dce/rpc client/server/parsing code.  where do you go
to update the LSA code?  separate daemons with their own directories means
that it's pretty clear that the 1,500 to 4,000 lines of code that deal
with issue xyz are specific to that issue, and don't involve any other rpc
services.

i am giving serious consideration to doing a proper "dce/rpc over tcp"
set, using the opengroup's dce code.  however, dce-1.2.2 is massive and
probably excessive.  the linux port took me three days to compile / set
up, and it still doesn't work.

luke