samba 4: a new configuration system?

Sebastien Estienne sebastien.estienne at gmail.com
Thu Jun 23 09:38:28 GMT 2005


hello,

I read all your comments, and it seems that most of them were
focussing on the backend of the configuration file: how can we store
these informations ondisk.

But i think from a Gui (or anyone who wants to "programmaticaly"
configure samba) point of view, the back end is not really important.
It will be fine if it's a text backup or an ldiff one, or even a mix of both.

We just need a programming api for task that sysadmin  do by editing smb.conf:
- add/remove/modify a share
- modify/read global settings
- etc...

And moreover for an external developper, he shouldn't care about the
backend of the config file, it should be abstract. Otherwise when he
wants to add a share he must check if it's stored in the textg file or
the ldb, moreover how can he knows that the share he is adding is not
already defined in another backend.

An other problem is the validation of data. i think validation of the
data shouldn't be done in the gui, but in the api (returning an error
code).

These problems have been faced by everyone who tried to build a gui on
top of text config file. (swat for example). I'm also posting here,
because i tried it, and noticed the problem, and i think that each
developper who tried to develop this kind of gui has duplicated code
that other already writtend to solve the same problem. (eg: smb.conf
parser).

And i think that these problems will be faced (and solved) again by
the people that will write the webserver gui (swat-ng) of samba 4.

So maybe this webserver gui could be split in 2:
- a programming configuration Api
- the webserver gui that would be a reference for using this api

So people that want to write other kind of gui
(windows/macosX/kde/gnome) won't have to rewrite that code, and simply
use the Api.

regards,
-- 
Sebastien Estienne


More information about the samba-technical mailing list