On Mon, 2 Aug 1993 09:47:23 EST Greg Monroe <[log in to unmask]> said:
>Since you're going to make folk think about their Template files, how
>about adding an INFO section combined with a new option/command to
>request it.
Good idea, but...
>1) A short paragraph describing the focus of the list. The default may
> be just the long name and comment info in the header file. Hopefully,
> listowners would be encouraged to customize it with a paragraph or
> two.
>
>2) The number of current subscribers.
>
>3) Some 'human language' descriptions of various key words in the
> header, such as "Subscription to this list is open to the public",
> "The list is run by xxxx whose mail address is [log in to unmask]", "The list
> is archived in [monthy, weekly,...] logs", "This list is available in
> digest/summary format", etc.
If it's a template, it's dumb text and none of the above. Sure, name and
title of list, no problem, number of subscribers if you insist. But a
template isn't a program, it can't go hunting into the list header for
paragraph-style descriptions. It can check any keyword and can
conditionally include or exclude bits of text, but there are about 45
keywords, many with a complex syntax and an arbitrary number of
parameters. Any keyword describing "who can do what" falls in that
category, and that includes all the important ones. Sure, you can write
text for the simple cases, like "Subscription= Open", but that means you
will sometimes have text like "Subscription to XYZ-L is open to anyone
who... heck, I can't figure it out, it's too complicated" :-) At any
rate, the template processor isn't enough of a programming language to do
that sort of things, and even if someone were to be courageous to do it
I'd then wish good luck to the poor list owners who try to modify it :-)
>Or, on the simpler side, it would make it easy for an automaticaly
>updated "complete list of lists" to be created with more useful details.
Actually it's not simple at all, because template files are not a
database and their contents may contain substitutions which would have to
be processed before the results could potentially be stored in a
database. In other words, there is no point storing a bunch of &LISTNAME
and &TITLE and .bb &KWD(BLAH) = YES into a database. You need to execute
these instructions with the right input and save the results. Now let's
assume you customize the template to give extra instructions to local
users. This is a very reasonable and logical thing to do: use the power
of the template processor to help local users without including
irrelevant and possibly confusing instructions in text being sent to
other subscribers. Should the database contains this local information?
Your local users are likely to be the main users of the database on your
local server, so the answer sounds like it should be yes. On the other
hand, remote users are a lot more numerous, so it should be no. And at
any rate LISTSERV can't know this is local information, it just knows
this is a .BB instructions which happens to look up the &WHOM variable
and look for XYZ.EDU in it.
The problem in my experience is that people don't bother documenting the
lists - there are maybe 2 lines in the header saying "The INFO-BLEH list
is a list carrying information about blehs". Maybe this is because they
feel it is not worth their time as the REVIEW command is not the ideal
way to get info about a list, maybe they just don't have time or aren't
interested.
Eric
|
