Implement new data backend
Calendar currently reuses EDS' ECalDataModel
and ECalDataModelSubscriber
. That code is essentially unmaintainable, and we can't just keep carrying it on Calendar forever.
We need to add a proper event backend that abstracts away the communication with EDS.
API Design
The following new classes need to be added:
-
GcalCalendar
: wrapper aroundESource
. Exposes the calendar name, whether it's visible or not, and asynchronous APIs to retrieve the events at a time range. -
GcalContext
: context object holding the data backend, and the wallclock. Single instance throughout the application lifetime. Context-aware objects receive this object at construction time. -
GcalObject
: context-aware object. Has a singlecontext
property. -
GcalTimeline
: object representing a timeline, from Unix 0 to infinity. Has APIs to add and removeGcalCalendar
s from it, and query events at a particular time range. -
GcalTimelineFilter
: interface representing an object that can filter a timeline. Implementations must provide a s-expression filter. This s-expression filter can change during the object lifetime. The s-expression will be used by the backend to create anECalClientView
.
The following classes need to be modified:
-
GcalEvent
: make it stateless in practice.
Open Questions
(TBD)