Bill,
I realize *you* know all that, but not every list owner has been running
a large system for 10 years, so here goes... When people are paying you
for new versions of a software product and you tell them that capability
X is present, you need a Damn Good Reason to remove this capability in a
future version. It had better be something old that can be argued to have
become obsolete. Even so, many people will complain. This is why one has
to be careful when declaring that something is supported.
If as a customer you have a need to do something that currently can only
be done through unsupported methods, you should state your requirement so
that we may consider the provision of a documented interface in a future
version. In most cases these documented interfaces are in fact more
convenient for the customer than the unsupported method. In some cases
they are less convenient, but at least you don't have to worry about them
disappearing in the next version.
From L-Soft's perspective, the format LISTSERV uses to store lists on
disk is none of the list owner's business. L-Soft needs to be able to
change it to add new functionality, remove limitations or improve
performance. The GET command returns a list of subscribers with various
flags in a format that is suitable for (1) saving as a backup on one's
disk, (2) exporting/transferring the list to another LISTSERV host
running the same version (or a more recent version) and (3) getting a
"super-REVIEW" listing of all the people on the list, including the ones
that are concealed. The use of the flag columns is not supported. Because
it is not supported, we were able to add the new REVIEW/EDITOR/NOPOST
options without making a major change to the list format that would have
made people even less happy. Similarly, because editing the LIST files
directly off LISTSERV's disk is not a supported operation, we were able
to significantly improve the performance of LISTSERV with large lists by
caching all sorts of additional data. If we had guaranteed that lists can
be edited directly, we would have been stuck.
However, if you have a need for a list of currently available options in
a compact, easy to parse format, this can and should be provided through
a standard command. I did know that people used the flag codes, but I
thought (based on the discussions on this list when flag codes were
mentioned) that this was done only to do the equivalent of QUERY WITH. I
did not know that some people used it to prepare statistics. Anyway, I'll
look into providing a standard method for that in the next version.
Eric
|
