Cosmo UI Data Model Proposal

Introduction

The Cosmo UI (née Scooby) was designed to handle just calendaring functionality. Now we want to extend the Cosmo UI to support more of the functionality of Chandler, such as handling tasks and displaying a dashboard. As such we need to modify the current data model to accommodate the new data types and some of the Chandler specific concepts such as stamping. In doing so it is expected that this data model will come to resemble Chandler's and Cosmo's. There will some differences in the models due idiosyncrasies of programming languages and programming environments, but we hope to capture the essentials. Areas where we deviate significantly will be highlighted elsewhere in this document.

Requirements

The following are explicitly required by dashboard functionality:

1. Support for "Generic" items
   • This means that a collection is a bag of items of various types which may include events, tasks and messages and other types.
2. Support for Stamping
   • This means that an item has various sets of attributes which give it its "is-ness", and that an item can be stamped with more than one set of attributes, so something can be both an event and a message and a task.
3. Support for Items in multiple collections
   • Items living in more than one collection is a key feature of the Chandler Data model

These next items are required due to implications caused by the above:

1. Revised Permissions Model
   • Right now permissions are very simple and based on the collection that an item is in. Obviously now this will have to change due to the fact that items can live in multiple collections, each potentially having a different permission level
2. Metadata For Stamps
   • Stamps should have metadata about the types of properties in the stamp so that editing panes can be dynamically created

Proposal

Item/Stamping Support

All Items are instances of a single Item type
Instead of having an Event type and a Task type and a Message type, we will have one single Item type which has the common properties of all item types (uid, name, date created, date modified, etc.)

Stamps hold type-specific properties
For every type of stamp, we have different stamp prototype, like EventStamp^?, MessageStamp^?, TaskStamp^?. Each Stamp prototype has metadata about the stamp (more on that later...) like the unique namespace of the stamp, and metadata about the properties in a stamp.

Stamps are stored as a property of each Item
Stamps are stored in a hash on each item called stamps. The key of the hash is the name space of the stamp (all stamps have a unique namespace.) Of course having to type item.stamps['org.osaf.really.long.namespce'].startDate is inconvenient, so there will be some convenience methods for getting certain stamps like item.getEventStamp(), item.getMessageStamp() etcetera.

Each Stamp is self-descriptive Stamp types have metadata which will include information about the stamp's namespace as well as information about each of the attributes that the stamp contains. This way, for example, the detail view will be able to dynamically draw the form info for any stamp, as the attribute information will contain data about the type of the attribute, a validator, the order it should appear in a form, etc.

Items in multiple collections

Collections are a property of an Item
The uid's of the collections that an item belongs to and which the user has access to (either through subscriptions or belonging to the user) are stored as a property of each item.

Changing collections is Simple
Adding an item to or removing an item from a colleciton is as simple as adding or removing that collections uid to the item's array of collection ids.

Persistence

(note: some of this is covered in XXXXXXXXX)

Items and Collections are smart
To get the items in a collection, you call a method on the collection like collection.getEvents(startDate, endDate). To save an item you call item.save(). Almost any method that requires client/server communcation and operates on collections or items are available as methods of items or collections.

The smarts are in the Collections
When data is deserialized from the server collections will get injected with something (still being discussed) which gives it enough information to know how to perform client/server operations. This could be a "conduit" - an object with methods and data for using a particular data source or a "transport info" object - just a data object with credentials (name, pw, ticket, etc.) which the model object would pass to the service.

Items use the Permissions of the least restrictive collection
Since an item can belong to various collections, each having different permissions policies, when tryiing to make a change to an item (including deleteting an item) the save method will cycle through the collections it belongs to until it finds one permissive enough, and then attempt to save using the "conduit" (or "transport info" or "data source" - TBD) of that collection. note - there is still some discussion on the list w/r/t this issue.

Recurrence instances are not "real" items
Items which recur (right now only items stamped as events) need to be able to provide the expanded-out instances of themselves for a given time-range. In addition, we need to be able to get from a collection all the events that occur in a given time-range, including non-recurring events, the master event of a recurring event, and any instances of a recurring event. Items which are instances will have a boolean property called "instance" set to true. Items that are instances cannot have any of their client/server methods called - attempting to do so will result in an exception. If you want to make a change to an instance, find the master item, make the appropriate changes there and save the master event. This is more or less what we already have.

Implementation

Class Hierarchy

Object Properties

BaseModelObject

Collection

Item

BaseStamp

StampMetaData

StampAttribute

EventStamp

• More or less same as existing "Event" object

TaskStamp