In message <199310272045.AA07181@aw137.>, "Vincent D. Skahan" writes:
> (John P. Rouillard writes:)
> > The answer is we are working on it. We are not sure exactly when
> > the config file will be here. I was up till 3AM this morning
> > trying to get all of my changes straightened out and working right
> > before I leave for LISA, so I can do a decent dog and pony show.
>
> cool...when and where is the show at LISA ?
Good question. Actually the dog an pony show was more meant for Brent
and Alan i(f he is going to be there), but I guess a few extra people
doing review wouldn't hurt. I am currently scheduling a list managers
BOF for sometime after 8PM on Tuesday, so the show won't occur before
the BOF.
> > How often to people change the listname.x files? Once a day, once a
> > week, once a month ... I am interested in changes to the following
> > groups:
>
> I could see the .info file changing rather frequently on a new list as you
> get the info you want to provide fine-tuned.
Yes, I could see that too. Actually I think it may not be a problem
because I think I have a scheme to allow Alan's method of single
keyword setting to work.
> > Also to the person who (sorry I lost the email, mailer driving error
> > at 2:30 ish) suggested that old config files should be automatically
> > checked into rcs before being supplanted, nice idea, but that would
> > need a mechanism to pull a particular revision of the file out to be
> > useful, so I don't think so. but I think all of the hooks would be
> > there to make an addon module do it.
I just realized that the full add in modules discussion (mixins if you
will) may not have made it to the list. This is the way I envision it
working:
majordomo loads all of the files in a directory "addins". Each addin
has perl code to register its new commands with the main majordomo
parser, and most importantly to provide help info for the commands.
Each addin could also register its keywords with the config file
parser, so that it would share the same configuration mechanism as
the rest of the majordomo package.
The addin code could easily provide stubs to trigger an autoload of
the real code when it is needed. This would help to reduce the startup
time. If a help directive was needed, the newly registered function
names would be displayed with a tag indicating that they were
non-standard majordomo commands. This should allow easy
differentiation between the standard and non-standard commands.
> Don't forget that we all do not have RCS...many of us are stuck with SCCS.
> Also, please make it an optional feature.
Actually I would like to make it a non-existant feature 8-). However,
since it should be able to be implimented as an addon (post_newconfig,
do_get_config_version ...), you just don't put the file implementing
the function in your addon directory. Also implementing one in rcs,
and one is sccss shouldn't be all that hard. Then a site can choose
which version of the "scs_config" package thay want. Heck you can even
create one based on cvs if you like.
-- 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 (until 10/29/93)
rouilj@bose.com Framingham, MA (508) 879-1916 x6483
===============================================================================
My employers don't acknowledge my existence much less my opinions.
References:
|
|
