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

Part 2 of 3...

2. The "Calendar Manager" should also be able to operate in an
   environment where the "/var/spool/calendar" directory only
   exists on a server machine. The client machines which run the
   "cm" process do not have a "/var/spool/calendar" directory at
   all. The "cm" process on the client merely communicates with a
   rpc.cmsd on the server and the calendar changes are made
   there. In this environment there should be no requirement for
   a local rpc.cmsd process.
 
Keywords: name service
 
Yes.
 
This is a good time to talk about name/authentication services.
Rpc programming is host-centric.  You must direct
your rpc call to a target host.  You ultimately have
to answer the questions:
        1. Client: Where (on what host) does that calendar reside?
        2. Daemon: Who are you (making the remote procedure call) and
           do you have access?  Prove it.
The means that the client software must obtain credentials for
the user wishing to gain access to the calendar, and it must
either explicitly specify the target (as it does now by
having user-defined "name@host" strings) or it must consult
a name map to get it.
 
FACT:
In a networked environment where naming and security are VERY BIG
issues, you must either:
        1. bring up a name/authentication service and institute a
        site policy that it will be used universally, OR
        2. replicate your passwd files across *every* host on
        your network and force the user to direct the software
        to the desired target host
IMHO, #2 (along with the absense of root passwds on host machines)
constitutes one of the biggest security holes you can introduce to
your network.  It also wrecks havoc with any sort of system
adminstration plan and it grows exponentially.

---------

3. The system administrator should have control over where users
   default calendars reside. This can also be a user option but
   must be able to be overridden by the administrator. Eg. if the
   administrator wishes to force calendars to a particular host
   the "Default Calendar" property should be "greyed" out.
 
Keywords: policy, name service
 
Software should not dictate matters of site policy.  If you want
your site to be maintained by a system adminstration staff, the
software should not stand in your way.  But neither should it
require the skills of a system administrator to set it up.
For sites which do use system administrators, I suggest that you bring
up a name service where you control the location maps.
The client software should, by default, consult it.
Ideally, the user should not know
nor care where his calendar data resides as long as:
he can get at it, it's backed up, it's private.
 
The "Default Calendar" option, BTW, is designed for the person
who typically maintains a calendar other than his own.
(e.g. secretaries who maintain their group's calendars; by default,
they want CM to come up on the group's calendar, not their own.)

---------

4. The system administrator should have control over where users
   mail should be sent by default. Larger sites usually have a
   host which is used for mail service. The "Mail To" property
   would not be greyed out as the user should have the ability to
   redirect the mail if they wish.
 
Keywords: name service
 
Or, the name service should know where the mail should go
and tell the calendar service when asked.
----------
--
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
Xref: sparky comp.windows.open-look:2120 alt.toolkits.xview:427