Re: Cone 20050629

Another usability/efficiency suggestion for cone.

If one is writing a longish email in an external editor, it is pretty
easy to have cone disconnected when you save and try to send.  I do this
four or five times a day, or so it seems.  I have then learned from
experience that you then have to ritually:

  Press return (to reconnect)
  Press W (to ask to "write" a message)
  Press Y (to agree to "continue" working on the message you just tried
to send, assuming it is the only one that is pending)
  Press ^X to send the message

to actually send the message (which might be something you don't want
delayed indefinitely) before you can resume workflow.  

That's a lot of extra work for something that is completely unnecessary
and that can happen several times a day times as many users of cone as
there end up being.  It also creates a completely unnecessary risk that
an important message is delayed indefinitely because a user doesn't
realize that they have to work through this ritual or just forgets to do
so to actually get the pending mail to go out.

I think it is pretty safe to assume that cone users want to connect when
they press ^X to send the message in the first place, if they aren't
(still) connected.  Send implies connect without exception, if
connection is a requirement for sending and a halted connection exists.
Cone should thus reconnect and send in this situation and then pop them
back into whatever state they were in when they began the message --
working through the mail folder they were working on right when they hit
"reply" or whatever -- with no additional keystrokes required.

I'm not entirely certain what the motivation is for disconnecting cone
at all on a timeout (thirty minute or otherwise), BTW.  I've always
viewed "we're doing this for your own good" diconnections as obtrusive
and probably useless -- if I abandon my computer unattended and
unsecured for even five minutes there is plenty of opportunity for
mischief.  "For the good of your server's load" disconnections also make
a lot of possibly unwarranted assumptions as well.  First of all, an
idle connection (e.g. when I'm writing a long reply) isn't terribly
resource intensive on either server or client side as a general rule.
Second, I might be (and in fact am) using a relatively lightly loaded
departmental IMAP server that could care less if I remain connected but
idle for more than 30 minutes.

No there MAY be environments where having a timeout/disconnect is a good
idea or necessary according to policy, but I think that the greater good
would be served by making the delay for a timeout disconnection a
user-selectable option, with a default negative value that stands for
"infinity" (no timeout disconnection).  That too would solve the problem
indicated above where one has to constantly reconnect to actually send
mail, as I'm likely to have to do to send this particular piece.

    rgb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCyrgPUfPgIH3s/SIRAqz7AKDGbYWC2GtJ0rytwXATBlXpkac9bgCfWv4N
3leMV6VbyPudg+jB4wr5ivs=
=HDqv
-----END PGP SIGNATURE-----