Re: Proposed changes to Calendar abstraction

[brian moseley <ix maz org>]

in my quest to add icap support, ive considered the
following alterations to the design.

first, some (re)definitions of existing and new objects:

 calendar: client-side aggregator of calendar objects
 service:  a data store and access protocol (cap, icap, sql,
           filesystem) with location information (perhaps a
           url)
 account:  authentication information that relates a
           calendar to a service

this fits in nicely with russell's work allowing a
GnomeCalendar to have relationships with many calendars. M
calendars can be owned by N services, represented by P
accounts (allowing for multiple accounts on a single
service).

i envision account manager gui similar to that of netscape
messenger: it supports a set of service types, and for each
account you create, you can associate it with one of those
service types. if you select icap, then ui for providing a
hostname and port and calendar id will be enabled; if you
select file, then simply ui for providing a file path will
be enabled. etc. there should also be a preference to
remember password on a per-account basis.

one possible design approach might be to provide a
CalendarService base class, with CalendarICAPService and
CalendarFSService subclasses. the base class can provide
url, username, and password attributes; subclasses can
choose to ignore the authentication information (the
filesystem implementation probably would). the base class
can also provide virtual load and save methods. then when
something wants to cause a calendar to be loaded or saved,
the calendar can delegate to the service provided by the
calendar's account.

we'd most likely want each service subclass to own the data
format - for instance, some services might manage ical
objects only, while others might manage vcal objects as
well, or translate vcal to ical, or whatever.

thoughts?