Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hplabsz!taylor
From: taylor@hplabs.HP.COM (Dave Taylor)
Newsgroups: comp.mail.elm
Subject: How to Implement Shared Mailboxes
Message-ID: <1658@hplabsz.HPL.HP.COM>
Date: 4 Mar 88 19:07:41 GMT
Sender: taylor@hplabsz.HPL.HP.COM
Organization: Hewlett-Packard Laboratories
Lines: 76

One of the things that I've wanted to implement in Elm for a while is
what I'll call shared mailboxes.  The idea here is roughly that there
are certain mailboxes that multiple people want to be able to interact
with simultaneously.  

The current solution is simply to send the mail to 'n' users, with 
each person ending up with their own identical mailbox.  As the 
messages are answered, the reply is *also* sent to the group address, 
which results in it being in the mailbox, and by this mechanism presumably 
things work out okay, at the price of a typically huge mailbox.

Well, that seems kinda not a good way.  

Instead, I'd like to offer a solution whereby you can bring up a mailbox 
in Elm (probably explicitly indicating that it's a shared mailbox somehow) 
at the same time that other people, perhaps connected by RFA or NFS, 
bring up the same box.  As mail arrives it is listed as `unowned', and 
any of the various members of the group can `take' a message, in which 
case it should then immediately be listed on the other users displays 
as being owned by that specific person.

Deletion of a message is held off until all parties leave the
shared mailbox (for synchronization purposes), and any mail that
is responded to (during that session) is then marked as REPLIED
and will automatically have Elm add an Expires: header to the
message -- a week later (for example) the message will then be
automatically purged from the mailbox.  (replying to a message would
also automatically cause the system to list the replier as the `owner'
of the message)

The mechanism that I'm thinking of for implementing it is to
have the user start up the program explicitly indicating that
the mailbox is to be shared, as in:

		elm -S /shared/postmaster.mail

which will then look for, and create if not present, a file called
".postmaster.mail" in the home directory of the mailbox.  That
file will be the basis for all interprocess communication between
the various instantiations of Elm -- with 'user connected', 'user
replied to', 'user took', and 'user left' messages appearing there.

The interface would indicate in square brackets as part of the 
subject display field the owner of a particular message, as in:

  R  4   Feb 24  Dave Taylor    (40)  [Karen] Why does this address fail?
     5   Feb 25  Jane Doe       (31)  [] Problems with your alias file

where the first is indicated as `owned' by user Karen and replied to, and 
the second as not yet owned by anyone in particular.

The reason that I'd like to use file-based communication rather than a
more legitimate RPC/IPC system is because there is no commonly available
standard for IPC systems ... whereas there are a number of different
ways to access files on a remote machine.

The two biggest problems with this are:

	1. It ugly.
	2. It isn't sufficiently reliable a mechanism -- if I connect
	   to '/shared' via NFS, am marked in the activity file as being
	   a member of the group reading the mailbox, then my machine
	   crashes, it'll never be able to ascertain that I'm not
	   there; it will never purge the file.

I'd like to request that interested members of the Elm users community 
at large discuss this issue further in this forum (rather than in private 
mail to me) and hopefully we can arrive at a good solution that will offer 
not just the functionality I'm discussing here, but will also support the 
two buzzgoals: heterogeneity and transparency along with reliability.

				Still trying to get 2.0 out the door,

						-- Dave Taylor

ps: I'll be in Bristol England for two weeks, so don't expect any
    blinding followups from me for a bit herein.  Thanks again.