Any interest in swat enhancement

[Andrew Tridgell]

> Would not a pipe to the process have the effect of queuing up the small
> messages?

we need all Samba processes and client utils (eg. smbstatus) to be
able to send messages to any other part of the system. That would mean
N^2 pipes, or a central messaging process. We don't want either.

> Then would the routine that was signaled then call the tdb routines to find
> out the message, or would it call:

the message would be in the tdb. The messages are meant to be small
(no limit as such, but large messages will be a bit slow).

> Wrapping the message retrieval from the tdb may allow you to explore other
> options with out having to change to much source each time.

yes, obviously :)

> It seems like the logical step would be to store the smb.conf file
> in a tdb

What I plan on doing here is to cache the config file in a tdb and
open that tdb read only except when re-generating. This would make for
fast smb.conf reload which is a factor on some systems.

> and have a program that could read an existing smb.conf file into it.  Of
> course there would also need to be a way to convert the tdb back into a
> human readable smb.conf as a dump.

I'd rather keep the master file in the current format and use the
database only as a cache mechanism to avoid re-parsing on each
connect. 

Where this won't work is if you have constructs like:

      include = smb.conf.%m

in that case the cache would be disabled.

> Any chance that your tdb could reside in a shared memory area since the
> amount of information that it would need to queue up should not be that
> large.

it already uses shared memory (via mmap) where possible.

> This communication method would assume that the sender and the receiver were
> on the same system of course.

yep. the tdb api would allow for remote access but I don't plan on
adding that.