New configuration backends for Samba 3 SoC project

[Ming]

2006/5/31, Avi Alkalay <avi at alkalay.net>:
> Some time ago I started to look inside Samba's source to see how to
> inject the Elektra patch.
>
> In general, programs use to deal with configurations this way:
>
> 1. Parse configurations from a conf file or other type of backend
> 2. Fill internal C structs with these configuration parameters
> --- End of configuration-related code and affairs with configuration
> files etc ---
> 3. Rest of the program accesses these C structs to define its "modus-operandi"
>
> So to switch to a different configuration backend, something between
> step 1 and 2 should be written for the transition time, and when
> stabilized, move entirely to become step 1.
>
> My impression (that could be wrong cause I didn't went very deep) was
> that the configuration retrieval infrastructure is being called too
> many times in too many places in Samba code. And I sent the following
> message that time:
...
> > dyn_CONFIGFILE is the variable that contains the configuration file name.
> > It can contain a key tree configuration root instead. But the problem

> This is what I mean when I say Samba has a spread configuration system.
>
> I don't know why it is so spread and being recalled so many times. I
> guess maybe because Samba's programs want to be aware of configuration
> changes. If so, the Elektra way of doing that is to setup some
> notifications with callbacks that will retrieve the modifications, and
> modify the internal C structs.
Does Elektra give notification if the configure file(smb.conf) is changed?

> I guess too that ldb is being used to store lots of data like long
> list of user accounts etc. If so, why the API to access ldb is the
> same to access smb.conf. Or I completely missunderstood the relation
> between smb.conf, ldb and the API for them all.
It will be easy  to wrap ldb.

> Regards,
> Avi
>
> On 5/27/06, simo <idra at samba.org> wrote:
> > On Sat, 2006-05-27 at 15:12 -0500, Gerald (Jerry) Carter wrote:
> > > Most of the lp_XXX() functions can be wrapped around
> > > a simple query call.  The main hurdles are smb.conf
> > > variables and the include parameter.
> >
> > A careful analysis on lp_XXX() calls need to be made.
> > In some places we call lp_XXX() quite much as we knew they were just
> > references to in memory strings.
> > We can't move to querying a db for each retrieval without suffering
> > major performance issues.
> >
> > We may end up requiring a cache system to not destroy performances.
> > (Think of how much lp_workgroup() is used (more than 200)).
> >
> > > In an ideal world we could have a virtual registry
> > > for configuration that could be pulled from multiple
> > > data sources: advanced options in a registry (I know
> > > I'll get flamed for that comment) and the admin friendly
> > > ones in the normal configuration file/backend.
> > >
> > > Even if we don't end up using libelektra, I'd like to
> > > have an abstracted interface rather than hard coding
> > > ldb calls.  And since ldb is still in flux some, it's
> > > probably safer to localize the ldb calls as much as
> > > possible.
> >
> > Jerry, the ldb api is not going to change that much and certainly not
> > the ldb syntax (which is in the end the ldap syntax).
> > Anyway, I think that for a registry style interface a simpler API make
> > sense. You just need to get set very specific and wellknown values, no
> > need for the powerful but complex ldap filter syntax or to fiddle with
> > ldif style programming to change a value.
> >
> > Simo.
> >
> > --
> > Simo Sorce
> > Samba Team GPL Compliance Officer
> > email: idra at samba.org
> > http://samba.org
> >
> >
>