[samba-tng] msrpc status

[Michael Ju. Tokarev]

Luke Kenneth Casson Leighton wrote:
> 
[]
> 
> weelll... chris hertel discussed over a year ago about doing a
> hierarchical smb.conf parser.
> 
> you could then do something like this:
> 
[]

I can suggest another approach.
Many daemons will use some common variables here.
Is it will be better to simply allow _any_ variable in smb.conf?
And allow passing to readparm list of interested ones?
And for "very private" ones one can use, for example, "daemon.varname = value"
syntax.
One thing is that in this case users will be unable to find tupos in conf.
But this is also avoidable, for example, we can build (dynamic) list inside
of testparm routine (so that unknown values will be detected only by testparm).
This will give users not so mach troubles, and can make soft simpler.
For testparm, there can be separate text file with (name,type) pairs
that are used by installed daemons (this will not require recompilation
of testparm if some daemon/component will be added/removed/changed).

> 
> > b) And I think that there should be something like "thread-safe" support.
> 
> argh.  no.  horrible.  :)  threads are non-ansi-c-portable.  you want us
> to exclude loads of people?  *sigh*

No, I do not say that there is must be mt mode. But there is may be mt mode,
and it is not so horrible. Many unices now have support for mt mode, and recall,
for example, pth library... It may be some difficult to implement, but not
so much. Again, recall, for example, socks daemon -- good example of this
(it uses threads if one are available).
Anyway, "threads" coding approach may make code clean (!).

> > independant of it's realisation.  But b) is more hadrer since there are a lot
> > of globals etc etc that should be eliminated. This can give also more accurate
> 
> yes.
> 
> > code and more structural organization of it, and helps with shared libs also.
> 
> also true.