dce/rpc "client" api

[Michael Tokarev]

Ok, I'm not a member of Samba Team.  But
please let me say something here too. :)

I think about scalability statements discussed in
this thread (and many other threads), together with
autogenerated code and sidlc, "modularity" (well,
clear design of api levels that currently badly
lacks production version of samba; this one (i.e.
well-designed api levels is the big good issue),
shared objects and small separate daemons and big
monolithic ones, and, at the end, about this
transport-abstraction (see subject).

Modular design, well-choosen api, autogenerated
interfaces, and scalability.

I'm not a samba guru, nor I'm an expert in protocols
and proposed APIs.  But that I think here is --

is it possible to separate things so that actual
"real" code that implements some service, transport,
etc will be "independent" of each other part to
the level when one can just replace daemon
architecture without chanhing that code?  Or,
replace transport level and have same set of
sercvices working, well ... on IPX or other
net transport?  (IPX here is just an example).

The point here is that (probably) the "heart"
of the system, i.e. actual daemon (smbd or nmbd
in case of current samba) can have architecture
sutable for particular needs in this case.
To switch to, say, separate daemons instead of
a bunch of dinamically-loaded .so files or
from a monolithic daemon can be done by just
recompiling code, without ever "#ifdef's" inside
"real" parts (not including the "heart" itself).
Or, some day we can decide to use threads for that
purpose, or even apache-2 (or Oracle in MTS mode)
approach...  Well, not all systems suppots that,
but who cares -- if it is that easily, why not
to use this...

I recall that I don't know if this is possible
and if the approach (auto-generating, dynamic
interfaces) taken can help here.  Maybe this
is complete crap.  But maybe not...

Also, the same words about tdb/state/etc across
daemons/parts/modules -- we have a shared memory
(on _some_ systems at least) that is a _best_
thing for most that purposes.  And it can be activated
with _well designed api_ inside samba.

As far as I understand, production version
have no clean designed api; but Luke always
proposed the _api_ first, or abstraction
levels...   This way, TNG seemed to be the
only real beast that can do the evolution...
Maybe Luke should not go _so_ further, but
who knows -- at least I just like his
approach.

Regards,
 Michael.


P.S. I'm shure that there are people out here
that will gladly support Luke's work so that
TNG can be complete another (alternative)
samba implementation...  It have so many nice
things in it...  Maybe Luke can just "fork"
the tng off the samba away completely, forming
a separate project?  This way is not good, I know.
But it is a real pain to see that difficultes
that samba team have now...