Rebranding moving code around.

[Stefan (metze) Metzmacher]

Jeremy Allison schrieb:
> On Fri, Apr 23, 2010 at 05:57:01AM +0200, Volker Lendecke wrote:
>> On Thu, Apr 22, 2010 at 08:27:23PM -0700, Jeremy Allison wrote:
>>> I know that's what tridge wants to do. I'm not clever
>>> enough to do that :-). My personal feeling is that changing
>>> the current Samba3 fileserver (renamed just fileserver) to
>>> use the Samba4 (renamed Samba-ad) directory services as separate
>>> processes using IPC is the way to go.
>> Having them united under the same architectural umbrella is
>> probably a worthwile long-term goal. But the Samba3 smbd is
>> still years away from being able to achieve that goal. As an
>> intermediate solution, I also think that using the standard
>> protocols for IPC between s3 and s4 is the way to go:
>> SMB[1,2], LDAP, MSRPC and so on.
> 
> Architectural umbrella is one thing, a single binary is
> another :-). I really think they should be separate cooperating
> processes communicating via RPC. Built out of the same tree
> using the same codebase, yes, but not in a single binary.
> I don't want to worry about destabalizing the AD server when
> I'm messing with the SMB2 server (and I'm sure vica verca :-).

My long-term plan is to make is possible to hide the single binary vs.
multiple binaries from the code. The components should always
communicate vs. RPC, IPC (messaging) even if they run in the same process.

If the code allows that it doesn't really matter if we
decide to build one binary with one process, one binary and multiple
forked processes or multiple binaries.

The one binary approach can also be extended to load services from .so
files, to make the main "starter" binary very small (that like the
openchange server currently loads into samba4's 'samba' binary).
Or we just make the "starter" generic so that you can pass it options
on the command line to let it start just specific services.

So I think our main goal should be prepare the code to all this possible
and then we can decide what do use based on "what is easier to use"
instead of "what is possible".

As short-term solution we need to find solution based on "what's
possible", I guess multiple binaries could be one solution (maybe
combined with some exec() wrappers to automatically start them).

But one of the problems I see is that we don't use the same messaging
code yet and source4 components can't talk to source3 components via
messaging.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100423/6e9bad85/attachment.pgp>