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