In message <m0ocVd3-0002wDC@hock.bolis.sf-bay.org>, Alan Millar writes:
> > I warn if the keyword isn't registered, ignore it and continue on.
> >
> > > In either case, it shouldn't bomb; it should just continue on to the
> > > next line with a message to the user that it was ignored.
> >
> > One problem, the user never sees the message unless they are in the
> > habit of running sendmail with the -v flag.
>
> Shouldn't this output be returned to the user?
Well, there is nothing the user can really do about it. What should
happen is that the error message is sent to the list owner. Just
haven't gotten a round tuit yet.
> > > Another thing I don't like about having to submit a new
> > > config file each time is the fact that I'll have to have
> > > Majordomo send me the current config file, edit it (which
> > > entails either writing it to a file, editing that, and
> > > mailing the file, or else using my mailer's Reply command
> > > and stripping off the leading ">"s on the whole file
> > > as I edit my reply) and send it back. All to change one
> > > little value.
Get a real mailer, I would suggest MH, although using supercite
withing emacs would work as well.
> > True, that's part of the reason my regression suite is so huge. Right
> > now I am up to 26 keywords to control majordomo and reply. Maybe its
> > time for a "config" perl script along the lines of approve?
>
> But a config perl script doesn't help changing the values
> remotely by e-mail, which remains a big pain in the neck.
Sure it does
show <results of config command> |
config 'moderate = yes' 'advertise = /flooble/'
Generates a new config file with the changes mentioned. Actually you
could just append the new keyword/value pairs to the config file
output since I parse things top to bottom, and duplicate keywords
override the values higher in the config file. This will probably not
be true if I have to support multi-entry commands (e.g. an array of
values for a keyword ).
> > >jr> What happens when one module needs to influence the way another
> > >jr> one operates?
>
> > I validate each keyword/value on a line by line basis, but I have to
> > check pairs of keywords as well.
>
> > > What sort of interkeyword checking is there?
>
> > Create the file <listname>.closed, now create the file name
> > <listname>.auto. What happens?? Same problem with the config file. I
> > bounce it if both auto and closed are defined since the person is
> > telling me they don't know what the hell they are doing. I can see
> > similiar conflicting options in many different areas.
>
> It seems to me that this is the only thing standing in the way of
> a set/show command syntax which could change one item at a time
> instead of reloading the whole file. (As you probably have guessed,
> I can't stand the idea of needing to reload the whole file each time.)
>
> I would structure the code so that there is a separate validation
> subroutine for *each* configuration keyword. Any cross-checks
> would happen there, and conflicting options should be set accordingly.
I actually have one type of subroutine for each class (boolean,
string, word, absolute file, absolute directory ...) of value, so I
just add the fucntions for auto, and closed (its just a table lookup).
No problem here. That also makes it possible to override the meaning
of closed, and provide a totally new checking function for it. Yes you
are right. The changes will be making their way in soon.
> For example, have a subroutine validate_closed and a subroutine
> validate_auto. Validate_closed would check its parameters, and
> also check the current auto flag. If the auto flag is on, validate_closed
> would turn it off and *tell the requestor that it did so*.
> Validate_auto likewise would turn off validate_closed and tell the
> requestor.
and then regen the config file. Yes that could work, except I would
prefer to boot the offending command and tell them why I booted it
rather than "fixing" it for them. For all I know they meant moderated,
and not closed.
> This sounds reasonable.
>
> > Every value that is successfully parsed is put into the array
> > %main'config_opts. The key is the concatination of the list name, and
> > the config file keyword e.g. bblisaprivate-which bblisamoderate etc.
>
> Should there be a separator between the list and the keyword, just
> in case there were two lists, one of which is a subset of the
> other, and the difference matched a keyword?
Yes, there should be. I'm putting in a `.' now.
-- John
John Rouillard
Special Projects Volunteer University of Massachusetts at Boston
rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480
Consulting Systems Programmer Bose
rouilj@bose.com Framingham, MA (508) 879-1916 x6483
===============================================================================
My employers don't acknowledge my existence much less my opinions.
Follow-Ups:
References:
|
|
