New configuration backends for Samba 3 SoC project

[Avi Alkalay]

On 5/31/06, Avi Alkalay <avi at alkalay.net> wrote:
> 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
>