SWAT demo

[Andrew Tridgell]

> Okay, I'm looking at SWAT from the 'smb.conf syntax' point of view.  If 
> at all possible, can you provide a clean demark so that changes to the 
> parsing and parameter access mechanisms won't cause too much difficulty?

the interface calls swat makes are currently:

lp_local_ptr()
lp_next_parameter()
lp_dump()
lp_killunused()
lp_load()
lp_do_parameter()
lp_remove_service()
lp_copy_service()
lp_numservices()

the most important ones for swat are lp_next_parameter
and lp_do_parameter. See loadparm.c for exactly what these do.
Note that nothing in swat ties us to the current smb.conf parsing. 

> > This looks good. Please can we make sure that for every parameter that has
> > a fixed set of options we provide only a set of on/off buttons for each.
> 
> This is adding a pseudo-enumeration type to the current stuff.  It's
> turning at the back of my mind.  In some cases we'll want to accept only
> one of the available options, in others we'll want to accept a set of
> them. 

we already have enumeration types in loadparm.c. That's how all the
enumerated stuff is handled! They were handled as integers in 1.9.17
but I changed that and added a proper enumerated type when I started
thinking about a web admin tool.

the most "tied to loadparm" function is lp_next_parameter() which
returns a pointer to a parameter structure that contains:

struct parm_struct
{
	char *label;
	parm_type type;
	parm_class class;
	void *ptr;
	BOOL (*special)();
	struct enum_list *enum_list;
	unsigned flags;
};

this structure was private to loadparm.c until last week when I made
it public by getting lp_next_parameter() to return it. I needed to do
that as the parameter passing in lp_next_parameter() was getting
unwieldy with the need for the enumerated types. 

> > Also, for parameters like "netbios resolve order" (yet to be implemented)
> > and "socket options" that have a fixed set of options could we list these
> > as a help to the administrator.

these two options are a cross between strings and a enumerated
type. Particularly "socket options" as it can't just be seen as a bit
list of on/off options. Many socket options take optional integer
values. 

That's why in the current swat socket options is a string. I don't
think that is a big problem as it is an advanced option and we just
need to get the help text ok so people can understand. I don't think
a lump of code to handle lists of enumerated and integer types in
one option is really justified.

> Part of my thinking, when considering the whole smb.conf thingumy, is that
> you should be able to ask for all available parameters and their
> acceptable values.

yep, that is exactly what lp_next_parameter() does. It allows you to
walk the list of possible parameters retrieving the types and (in the
case of enumerated types) lists of acceptable values.

>  Once the syntax is down (working on some ideas, and
> yes I'm aiming at backward compatibility), it shouldn't be too hard to
> come up with a structure to hold a definition of availalbe parameters. 
> (In fact, such a structure *could* be used to manage and edit X Resources
> and the like.)

that's exactly how swat works. swat has no real knowledge of Samba
parameters. It just walks the list offered by loadparm.c

Cheers, Andrew