Architectural issues

[hanna@xxxxxxxxxxxxx (Stephen R Hanna)]

All this discussion of data representation is great. I'm glad to see
things converging on a simple set of property-value pairs.

As I understand the discussion in July, the group decided to start
several simultaneous efforts. One would focus on defining a format
for representing C&S objects. Another would focus on defining a set
of verbs which can be used to manipulate these objects. A third
effort would define the architecture of the system, focusing on agents
and roles. Others were working on the charter for the proposed WG.

Where do these other projects stand? I'm most interested in the
verbs and architecture (agents/roles) discussions. Anybody care to
chat about those?

*Architecture (agents/roles)*

For architecture (agents/roles), I would suggest that we allow for
several usage scenarios:

Client-server: A protocol is defined that allows a client to receive
appointments from a server and send appointments to others via the
server. This would allow any client to be compatible with any server,
like POP3 or IMAP.

Interoperability: A protocol is defined that allows one scheduling
system to send appointments to another scheduling system or respond to
proposals previously received. This will allow scheduling systems to
interoperate so that appointments may easily be sent to any one,
regardless of what scheduling system they use. Changes to appointments
and responses to appointments may be sent the same way.

Free-form: The same objects used in the previous scenarios
(appointments with verbs) may be stored or transmitted via any
mechanism (email, WWW, or floppy disk). The user may deliver an
appointment object via drag and drop, clipboard, or other mechanism
and it can be incorporated into their calendar. Optionally, the
protocol described in the interoperability scenario above may be used
to establish a link between the user's calendar and the appointment's
originator so that appointment changes and responses may be exchanged.

*Verbs*

For verbs, I would throw out the following as a first pass:

appt-announce: Announces an appointment. May also be used to announce
changes to an appointment. This verb would be used in all three
scenarios.

In client-server, clients announce new or changed appointments to
their server and the server announces new or changed appointments
received from elsewhere to the client. In interoperability, scheduling
systems announce new or changed appointments to each other. In
free-form, most objects will use the appt-announce verb because there
may be no protocol for following up with other verbs.

appt-respond: Responds to an appointment. May be used to indicate that
an attendee will or will not be able to attend or to supply comments
from an attendee. Actually, this verb could be subsumed by the
appt-change-request verb. See that verb for more details.

appt-change-request: Requests a change to an appointment. This verb
could be used both to replace the appt-respond verb described above
and to allow the client to change an appointment in the client-server
scenario.  Objects with this verb should probably include only the
properties that are being requested to be changed (and any other
properties required to establish the object's identity).

In the client-server scenario, clients can send appt-change-requests
to their server to change appointments. In the interoperability
scenario, one system can request a change to an appointment that is
owned by another, but this request may be denied based on the identity
of the requester and the changes requested. In the free-form scenario,
objects with appt-change-request verbs may be created and sent, but
there is no defined protocol for transmitting them or receiving any
appt-announce verbs that might indicate whether the changes were
accepted.

*Architectural Concerns*

I believe that we may be operating under different assumptions about
what an appointment is. I'm sure that the architectural model of our
product (Meeting Maker XP) has a profound effect on my understanding
of the problems we're trying to address and the solutions we choose to
use. In the interests of openness, I'll share these assumptions with
the rest of you and ask that you do the same for me.

For our product, an appointment is an event with at least one time
associated with it. It may have a title, an agenda, a guest list
(including resources such as a slide projector), one or more
locations, etc. I want to focus on the roles/agents of our model, so
I'll skip any more discussion of event-specific data.

One of our key customer requirements is that we manage access to this
appointment, allowing authorized users to make changes to the
appointment and making sure that all guests (including CC guests) are
informed of these changes.

This model has several implications. In order to track changes to an
appointment, we assign each appointment a globally unique id. This
allows anyone to receive changes to an appointment and match them up
with the old version of the appointment.  I believe that the concept
of a unique appointment id will serve us well in defining a standard
for communicating about appointments.

In order to control access to an appointment and maintain a single
authoritative copy of its properties, each appointment has a single
owner that receives change requests from other agents and announces
changes to all interested agents.

These two concepts (object identity and object ownership) are crucial
to our model of how appointments are managed. We use a client-server
model with distributed object databases connected via RPCs, but I
believe that these two concepts are generally applicable in this
problem domain. I would be interested to hear from others whether they
consider these concepts equally important.

Looking forward to some interesting discussions,

Steve Hanna
ON Technology Corporation
hanna@world.std.com
(617) 692-3153