Subject: Re: Pine 3.86 not including contributed code

From: Terry Gray <[email-masked]>
Date: Sat, 16 Oct 1993 07:40:07 -0700 (PDT)

On Wed, 13 Oct 1993, M. Dimou-Zacharova wrote:

> I sent the following message last friday and got no answer so far.
> I got pine 3.87 in the mean time and saw that the lock-in-home-dir
> option was still not considered insteresting.
> Please, don't think that I am 'agressive' on this matter. I just
> want to confirm you got my message and find out your opinion.
> I have thousands of users at CERN who access mail via afs , want to have
> several pine and simultaneous elm sessions from different hosts and
> the default locking in /tmp doesn't help in such cases.
> Thanks for considering these thoughts

Maria,
My apologies for our not responding sooner... as you can imagine, things
have been fairly hectic lately.

Attached is a message that Steve Hubert sent to you and Markus on 21 Jul 
indicating that we probably wouldn't include the contributed changes for 
locking in home directories, and inviting further discussion --which was 
not forthcoming.

You mentioned in your original msg that "this feature of allowing locking
in the user's home directory (if defined) is harmless and very useful."

We discussed the locking situation further at our weekly development
meeting yesterday, and concluded that while locking in /tmp *is* a problem
in your environment (where a single /tmp is not globally available on all
machines), the proposed solution is not completely harmless, which is why
we are still a bit reluctant to encourage lockfiles in home directories. 

The problem is with the shared mailbox case.  Pine and imapd locks mediate
access not only between a single MUA and the delivery agent (which agent
presumably *can* be taught to find the lock file in the user's home dir),
but they *also* mediate access among concurrent sessions, of possibly
different users.  In the multiple user case, a process running on behalf
of one user has no knowledge of who else might be accessing the mailbox,
so would be unable to know where to look for the lock file.  If you are
using tenex or mbox drivers, it's even worse, since access to both the
inbox and the spool file has to be mediated.

If you don't allow (or at least don't advertise the possibility of) shared
mailboxes, this shared case may be of small consequence to you, but we 
are finding it increasingly useful and popular, so you can understand 
why we are concerned about giving the home directory lock approach a 
stamp of approval, even if only via an IFDEF.

We believe that the ideal model is to organize things so that *all* the
processes that directly manipulate a particular mailbox are actually
running on the same machine.  That doesn't mean running Pine on a file
server, of course, but it does mean running IMAPd on whichever machine the
mail is actually delivered to.  I realize this suggestion is not 100%
helpful if the delivery agent has been modified to accommodate non-IMAP
clients by looking for lockfiles in home directories. 

So the choices seem to be:

1. Use /tmp for lockfiles, with all processes directly manipulating a 
   mailbox running on the same machine.
   Pro: solves all locking problems even for multiuser shared mailboxes.
   Con: implies using only IMAP clients, or having a shared /tmp

2. Use NFS or AFS -mounted mailboxes with lockfiles in $HOME
   Pro: allows for concurrent non-IMAP and IMAP access to mailbox
   Con: precludes multiuser shared mailbox access, even in pure IMAP case
        (and in the NFS case, there are other problems.)

3. Postulate a "global" /tmp alternative, e.g. /gtmp
   Pro: allows for imap and non-imap access, and shared multi-user access.
   Con: highly non-standard; requires changes to all mail programs used.

4. See if it is feasible for the delivery agent to look in both places for
   lockfiles... on the assumption that users will not be trying to run elm
   and pine *simultaneously*.  (This also assumes using Pine in IMAP mode,
   but I can't think of any reason *not* to do that...)

5. Try to think of a clever solution using links... 

Comments?  Other suggestions?

-teg

---------- Forwarded message ----------
Date: Wed, 21 Jul 1993 15:21:43 -0700 (PDT)
From: Steve Hubert <[email-masked]>
To: Markus Baertschi <[email-masked]>
Cc: Sheryl Erez <[email-masked]>, [email-masked],
    [email-masked]
Subject: Re: Pine port to AIX 3.2

Markus,

   Pine has changed quite a bit between our last release and the current 
development source, so it is a little tough to integrate ports.  We do 
have an AIX 3.2 system to work on and have a version that compiles and 
runs there.  Perhaps when we are just a little bit more stable (couple 
weeks maybe?) you would be interested in testing on your AIX system.  If 
so, we could send you an alpha-version to try to compile and run there.

   I don't believe we will include your LOCK_IN_HOME change in the 
source, however.  If you wish to try to convince us of that write back 
and we'll discuss it!  Thanks.

Steve Hubert <[email-masked]>
Networks and Distributed Computing, Univ. of Washington, Seattle