From: nannette@sunsol7.Eng.Sun.COM (Nannette Simpson)
Newsgroups: comp.windows.open-look
Subject: SUN Calendar Manager - Part 1
Date: 15 Apr 92 23:49:36 GMT
Reply-To: nannette@sunsol7.Eng.Sun.COM (Nannette Simpson)
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
NNTP-Posting-Host: sunsol7

Part 1 of 3...

Thanks to everyone who sent comments regarding
Calendar Manager and thanks to Craig Bishop
for coordinating your suggestions into coherent
form.  We are currently evaluating your requests
with respect to our future development plans.
Although we can't guarantee that your requests
will be implemented, all comments and suggestions
are valued and will receive consideration.
The standard channel for reporting bugs
and requests for enhancements (for any Sun
product) is to consult your local Sun support
office.  A report will be generated
for our bug tracking data base from which we
take input for standard software releases.

That said...

Response/comment to survey
--------------------------

1.      The "/var/spool/calendar" directory must be able to be mounted
        from a remote machine via NFS. Whether the "/var/spool/calendar"
        is mounted directly or via the automounter should not matter.

Keywords: Log files, NFS, and garbage collection

I think what you're asking is to be able:
        1. to centralize calendar data on one (or a few) hosts
        2. to allow the user to be mobile from host to host
                having his calendar follow him without loss
                of data or reminders
        3. to have automatic backup and ease of system administration

Mounting is the traditional method of achieving these goals through
the *file system*.  If the desired effect could be obtained
another way, would you care about the implementation?
Contrary to an earlier post, having your backing files exposed and
available for NFS mounting is not synonymous with distributed computing;
the client-server model does extend beyond the file system.  The use
of a human-readable transaction file for backing store was an implementation
choice; it could just have easily been a data base, Postscript, a compiled
file or some other less-accessible representation. The backing store is "owned"
by the service, not by the client and, certainly, not by the user.

Calendar Manager (client) requests that transactions be made on
its behalf through a client-side library which makes remote
procedure calls to rpc.cmsd (daemon,service). The daemon logs every
transaction in a file, /var/spool/calendar/callog.user,
and the log is replayed (parsed) at tool startup
time.  The use of logging guarantees that the state
of the calendar can always be restored to within one
transaction.  The daemon also maintains a data structure
in memory which represents the state of the parsed log.
The daemon consults this data structure, not the file itself,
when answering queries; and it garbage collects the data structure
back to the log daily.

Here is the problem with machines mounting the
/var/spool/calendar directory:
 
        -----------     -----------
          Host A          Host B
         rpc.cmsd        rpc.cmsd
        -----------     -----------
             |               |
             v               v
        ---------------------------
                Server A
                callog files
        ---------------------------
 
Each rpc.cmsd has a data structure representing:
 
        the callog file at startup time, plus ...
        any transactions that were directed to the host on
        which the daemon resides.
 
Since there is no peer-to-peer communication, the "world" view
becomes inconsistent the moment one or the other daemon
transacts the file.  It's much like two people editing the
same file at the same time.  Each daemon
wakes up daily to garbage collect its data structure
back into the callog file; whichever daemon
garbage collects last, "wins." That is, its
data structures are written out at the expense of
the other daemons.  All previous state is lost.
 
FACT:
*Any* software which maintains its own data structures
in memory and uses NFS to back them can potentially have this
problem.  The NFS protocol is stateless.  The server
does not remember from one transaction to the next
anything about its clients, transactions completed or
files operated on.
 
-------
--
Nannette Simpson			Internet: nannette@Eng.Sun.COM
Sun Microsystems, Inc.			UUCP: ...!sun!nannette
2550 Garcia Ave. MS 1-40		Phone: (415) 336-2969
Mountain View, CA 94043			Project: Calendar Manager