New configuration backends for Samba 3 SoC project

[Avi Alkalay]

On 5/30/06, Ming <mingwxia at gmail.com> wrote:
> If we use libelektra,we need to implement a backend in libelektra
> which probably named
> libelektra-smb.so(http://www.libelektra.org/Library_Linkage_Architecture).It
> should parse the smb.file and implement a set of interface used by
> libelektra.so.Further more in order to maintain the other samba server
> part changed as few as possible to use the new configuration backend,
> We might wrap the libelektra.so interface to what smb team already
> used.

I don't think that a libelektra-smb.so (something that reads smb.conf
and expose it through Elektra key/value pairs) is usefull.

In the X.org patch we kept the xorg.conf parsing code and used it to
provide the parsed key/values. So the first time a patched X servers
runs, the key/value tree is built based on current xorg.conf file and
next times it runs configuration is being read only from the key/value
tree, and xorg.conf is not being accessed anymore.

> Yes and I'm not clear how the other parts use the smb.conf backend(all
> through lp_**?). Should we implement the new configuration backend as
> a new set of get/set interface, that will bother the other server
> part,I think.
> > 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.

Some functions I don't remember the name (maybe the lp_XXX() ones)
parse smb.conf and call param/param.c::pm_process() to fill internal C
structs. So an Elektra patch would reimplement the callers of
pm_process() and call it for each key/value found. The problem is that
the callers of pm_process() are spread all around Samba's source and
are of many different types. And they use as parameter a variable
called dyn_CONFIGFILE which seems overused in may places too.

Regards,
Avi