Notes on Bedework design

Bedework has evolved from UW calendar and gradually deveoped a new structure over time. These pages attempt to describe the direction we are heading in and some of the reasons for decisions and statements.

Big Picture

The big picture is essentially a 3 layer structure. (Link to picture from powerpoint).

At the top we have the applications and tools. All of these communicate through the service layer which represents the api - defined in CalSvcI. CalSvcI is bedework and as such provides services for general calendaring functions and CalDAV as well as support for bedework specific functions such as syncml and dumping data, restoring data, etc.

The api level communicates with the actual data via implementations of CalIntf?. Calintf is intended to eventually support only calendar information as defined in the various RFCs. This allows us to have a system which allows subscriptions to external data via (for example) calDav.

External Subscriptions and their implications

The subscription mechanism implemented in CalSvc? is based on urls. There is a bedework specific mime type which is intended to flag the url as referring to bedework data. It should be possible to implement a system which gives access to multiple bedework datastores. CalSvc? needs to look up the implementation - through the factory mechanism. Currently it calls getCal() to obtain a class - it should provide the url. This would allow some sort of federated calendar system, we can imagine perhaps a global datastore for public events related to an institute as a whole and separate store forlarge sub-organizations.

A second harder target would be to develop a CalDAV based implementation ofCalIntf. The current Calintf definition doesn't make this too easy. There are a number of bedework specific features which make this impossible.

Calintf changes needed

The overview above represents the desired state of affairs. Unfortunately, due to the evolutionary nature of the system, we are some way from being able to develop a CalDAV implementation. Some of the problems need to be resolved in the short term as functions are already being developed assuming a structure which will not exist in the longer term.

An immediate requirement, because SyncML implementation is moving along, is to move SyncML support up entirely into the CalSvc? layer. This is a fairly small amount of code and should be moved into CalSvcDb?.