On Wed, 23 Apr 1997 13:05:41 -0400 Vince Sabio <wavelet@colossus.arl.mil>
said:
>For newbies, this is simply too complex. All I'm suggesting is that MLMs
>recognize and properly process Approach #1 in *BOTH* cases -- confirmed
>subscriptions and unconfirmed subscriptions. (...) it makes things MUCH
>easier for newbies.
I'm sorry, but I can't agree with that. First off, I've spent enough time
in my user support days trying to explain what a "pending directory
change" or a "pending disk allocation" was to confused users to know that
this is NOT an intuitive concept at all. The problem is that there is no
real life equivalent to this concept. Sure, your credit approval may be
pending, there is no great difficulty in understanding that part of the
picture. But you certainly can't move this pending money between your
various accounts or transfer it to another bank or another person's
account until the credit is approved and it turns into actual money. Your
pending money doesn't show up on your account statements and is for all
practical purposes not there, and this is exactly the way Joe User
expects things to be. Of course sometimes it can make sense for a
programmer to use a pending transaction, but this does not mean it makes
sense to exposure users to them. Besides, I've lost count of the number
of security holes that were caused by pending transactions being released
incorrectly due to a weird combination of factors, or pending
transactions being taken at face value because a fix written by a new guy
in the support department forgot to check the "pending" flag, or finally
because the grooming code which trims pending transactions that appear to
have become orphaned (the process responsible for approving them does not
seem to have taken any action) had a bug and did not make a necessary
change in a co-dependent pending transaction, which did get approved
eventually and led to incorrect behaviour. Again there are cases where
you just have to do it this way, but subscribe + set options is
definitely not one of them by a long shot.
Also, I am not sure I agree that "newbies DO find the not subscribed
message to be confusing". Obviously for any particular behaviour you will
always manage to find a confused user :-), but LISTSERV does tell you:
A confirmation request is being mailed to you. Please wait until it
arrives before sending any SET command, or any other command that
requires you to be subscribed to the list, as you have not yet been
added to the list.
I think this makes it pretty clear that you have not been subscribed yet,
heck, it even says explicitly not to send SET commands. It may not have
the drawing showing the power cord and how to plug it into a mains
outlet, or the little safety booklet with the drawings where you can tell
a mains outlet from a TV channel plug, but I think what newbies are
likely to be confused by is the confirmation process itself (which makes
absolutely no sense to someone who doesn't understand the underlying
security issues), and not the fact that SET commands do not work as per
the warning.
Finally, I think we have built a theoretical case here which is just not
present in practice. Our assumptions so far are:
1. User is a newbie.
2. User sends SUBSCRIBE and SET DIGEST command in same message.
3. User has a requirement that at no point in time should there be a
state, no matter how short, where user is subscribed to list and may
receive regular posting if such posting were to be generated in the
interval. In other words, the transaction must be atomic.
4. User can figure out confirmation instructions.
5. User cannot figure out warning about not using SET until subscribed.
Well, I don't know. Most newbies have no idea what a digest is in the
first place until you explain it to them and show them an example :-) And
I really can't think of any reason why a newbie would need to ensure that
no regular message is ever received. In most cases the turnaround for a
confirmation is under a minute, and even very active lists only have a
couple hundred postings a day. This sounds like the kind of concern you
have when writing a script to add a user from a web page, in which case
you can use whatever syntax will get the job done.
Eric
Follow-Ups:
|
|
