Subject: coupla' client issues

From: Mike Macgirvin <[email-masked]>
Date: Wed, 27 Oct 1993 10:18:38 -0700 (PDT)

This is kinda' convoluted, so bear with me ---

	I'm implementing several of the mailbox management features such as 
CREATE/DELETE/RENAME and the logistics are a bit crazy ...

	The c-client functions which implement these features require an open 
"MAILSTREAM *", and the current code I have (which works) runs through our 
internal list of open streams, and tries to match on the host on which the 
operation is desired. Otherwise the operation is dissallowed.
	But this is a bit inconvenient at the user level when one wants to do 
mailbox management on different hosts; because they aren't told until after the
fact that they have to open something on each desired host before they can do 
routine management stuff.
	I guess I'm trying to push a case for a function which opens a 
connection (and authenticates if neccessary) -without- doing a SELECT, for the 
sole purpose of supplying an open stream to do this management stuff. The 
alternative, I guess is to just mail_open INBOX, but it seems like it would be 
an unnecssary burden in the case where somebody just wants to rename one of 
their mailboxes on host2, but otherwise, they're working from host1.
	Is there perhaps a better way to go about this?

	A related issue, is it legal to delete/rename an open mailbox? The 
IMAP2bis draft doesn't appear to mention this. Are there any gotcha's that the 
client side should account for? Such as, is the mailstream still valid in the 
case of delete ? (probably not), and should the mailstream be refreshed (closed
and re-opened) in the case of rename, so as to maintain consistency ?

mike

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Oct 1993 12:32:53 -0700 (PDT)

Mike -

     Are you saying that mail_create(), mail_delete(), and mail_rename() don't
automatically open an IMAP connection as necessary if a MAILSTREAM argument
isn't supplied?

     If so, I think you're working with an old or buggy version of c-client.
I think what you want is already there and working in current versions; just
supply a NIL argument for the MAILSTREAM argument.

     My feeling on the question of delete/rename of an open mailbox is that it
should be avoided.  I don't think it's a good idea to specify this behavior in
IMAP2bis, since I'm not sure it is reasonable to require an implementation to
enforce either possible behavior (permit it or refuse it).

     I consider the behavior in this circumstance to be undefined in c-client,
and suggest that if your main program can avoid it happening, it should do so.

     But, if you feel that it should be defined in IMAP2bis, by all means
bring it up on the IMAP list.  I'll argue against a definition on the basis of
implementation difficulty (it'll be hard to make either completely right in
the c-client based stuff), but that doesn't mean that a definition won't
happen.  It depends upon what other people, especially other implementors,
feel!  ;-)

-- Mark --

---

From: Mike Macgirvin <[email-masked]>
Date: Wed, 27 Oct 1993 12:42:19 -0700 (PDT)

>       Are you saying that mail_create(), mail_delete(), and
>  mail_rename() don't automatically open an IMAP connection as
>  necessary if a MAILSTREAM argument isn't supplied?

>  just supply a NIL argument for the MAILSTREAM argument.

	Gee, I never tried ...  Thanks. 

>       My feeling on the question of delete/rename of an open
>  mailbox is that it should be avoided.

	That's why I asked. It will involve a bit of extra checking, but for 
the same reason as I wasn't aware a stream would be opened automatically, I 
like to err on the side of paranoia.

>       But, if you feel that it should be defined in IMAP2bis,
>  by all means bring it up on the IMAP list.  I'll argue against
>  a definition on the basis of implementation difficulty (it'll
>  be hard to make either completely right in the c-client based
>  stuff), but that doesn't mean that a definition won't happen. 
>  It depends upon what other people, especially other
>  implementors, feel!  ;-)

	From an end-user perspective, the underlying "system" would be a lot 
more invisible if delete/rename on open mailboxes were the same as any other 
mailboxes. But this doesn't have to a protocol level decision. It can be 
implemented on the client end by shutting the stream if necessary prior to the 
operation, and re-opening in the case of rename. But the fact that the 
behaviour is undefined (and possibly dangerous) is something that implementors 
should be aware of.

mike

---

From: Bill Yeager <[email-masked]>
Date: Wed, 27 Oct 1993 13:41:00 -0700 (PDT)

> 
> 	From an end-user perspective, the underlying "system" would be a
> lot  more invisible if delete/rename on open mailboxes were the
> same as any other 
> mailboxes.

I'm on Mark's side here. I'd categorically vote no. I guess that's what comes 
from having implemented an imapserver. The subtle problems that might arise 
sort of make me nauseous.

Bill

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 27 Oct 1993 19:43:45 -0400 (EDT)

I haven't written the code yet, but I was planning on having the Cyrus
imapd "* BYE" any client which had open a mailbox being renamed or
deleted.  The exception would be INBOX--on a rename, it would appear
as if someone had deleted and expunged all messages in the mailbox.

-- 
_.John G. Myers		Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up