From: Andrew Tridgell <tridge@samba.anu.edu.au> To: crh@NTS.Umn.EDU Subject: Re: SWAT demo Message-Id: <19980314020037Z12646289-21312+13217@samba.anu.edu.au> Date: Sat, 14 Mar 1998 13:00:20 +1100
> 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