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

Part 3 of 3...

5. The browse feature must also use the default calendar set by
   the user or the system administrator. At the moment it always
   uses "username@local_machine" regardless of what the default
   calendar is set to.
 
Yes.  That's a bug.

----------
 
6. Sun need to publish specifications of the "Calendar Manager"
   protocol. Users want to create alternate front ends and be
   able to extract the calendar information using other tools. An
   example would be producing an interface to a hand held
   calendar device like those provided by "Sony" and "Casio".
   Another would be a interface for users of PC's in a mixed
   environment of PC's running PCNFS and Suns.
 
Keywords: library, documentation
 
Yes.  Many of you already informally received my library and
documentation (such as it is).  We're working with our marketing
and documentation group to make this a real thing.

----------
 
7. In an environment where all the "local" users calendars are
   stored on a server the "Calendar Manager" daemon should allow
   users to access other users calendars via their username
   without a hostname extension. The hosts.equiv file could be
   used to establish that "local" users are involved.
 
Keywords: name service
 
Or, the the location of the calendar is specified by the name
service and is opaque to the user.  He would need only specify
the username within his domain or username@domain if going
across domains.

------------
 
8. In a server type configuration as described above in feature
   number 2, the "Calendar Manager" process must be made
   resilient to server crashes. It should automatically reconnect
   to the server and inform the user of any missed notifications.
 
Keywords: multiple instance
 
Yes.  This is somewhat difficult to implement as you might imagine.
You have multiple instances of tools on the same host bound to
the same service.

FACT:
The granularity of rpc programming (program number, version number,
procedure number) does not support multiple instances of services running
on the same host.  (It supports multiple *versions* just fine, just
not multiple *instances*.) Nor does it lend itself to callbacks of
multiple-instance clients which are distinguished merely by process ids.
It's left to the service implementor (if he wants to support
multiple instances of the service) to provide a multiplexing
layer on top of the service stub which fans the calls out to the
correct instance.

-----------
 
... That's it for the survey.  Comments are welcome.
 
        Nannette Simpson	<nannette.simpson@Sun.com>
	SunSoft Engineering

        Nancy Howes		<nancy.howes@Sun.com>
	SunSoft Engineering

        Warren Hogg		<warren.hogg@Sun.com>
	SunSoft Product Marketing

        Lorraine Fox		<lorraine.fox@Sun.com>
	SMCC Product Marketing


--
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
Newsgroups: comp.windows.open-look