On Tue, 25  Jul 1995 08:19:17 -0400  Roger Burns <[log in to unmask]>
said:
 
>So  I'm  requesting  that  there   be  some  kind  of  locked-but-queued
>alternative, so that I and other  list-owners won't need to be shy about
>locking our lists  when we make changes to our  headers. Again, I really
>don't want to lose any newbie subscribers who may get discouraged by the
>"can't handle  it now" message that  is currently generated by  a locked
>list.
 
That's all  fine and  well, but  saving and reissuing  the requests  at a
later date would create a whole new  set of problems - problems which are
much, much  more difficult  to understand for  newbie users  than "sorry,
can't  do now,  try again  later".  No matter  how  you look  at it,  the
commands can't be  executed right now and  the user has to  be told about
that. So, some users will get confused no matter what. Others will resend
the commands and  wonder what is going on, and  when they're all executed
all of  a sudden and  produce unexpected  results, they'll get  even more
confused and  discouraged. Imagine a  keyboard buffer that  executes what
you type the day  after you typed it. You turn on your  PC in the morning
and it does things you'd entered the day before, before going to bed. You
don't even  really remember and  there's no way  you can stop  it because
it's over  before you  realize what happened.  That's what  you're asking
for.
 
  Eric