unify common parts of events and todos?

[Michael Büttner]

i was working on switching recurring todo's back on when i noticed that
there are possibly some design flaws with the implementation of events
and todos.

the main cause of problems is related to the issue that events have a
startDate/endDate and todos have an entryDate/dueDate, both of them
having nearly identical semantics. the first problem is that the
different names of those attributes force clients to ask for them
conditionally, one particular example is
http://lxr.mozilla.org/seamonkey/source/calendar/base/content/calendar-month-view.xml#1023
some more examples can be found in the dialog related stuff in this
patch: https://bugzilla.mozilla.org/attachment.cgi?id=225247

but my main concern is with the generic backend stuff that needs to ask
whether it is currently dealing with an event or a todo in order to get
or set the appropriate properties (DTSTART,DTEND,DUE). there are
numerous places where the backend needs to know about specific
implementations of calIItemBase in order to perform requested
operations. this seems to break the object oriented approach.

it would be advantageous to circumvent those conditionals since it's a
great deal of asking for trouble. i hope folks agree on this. what i'd
propose is to do the following:

1) move 'attribute calIDateTime startDate;' from calIEvent.idl to
calIItembase.idl and remove 'attribute calIDateTime entryDate;' from
calITodo.idl. events and todos would map this attribute to the 'DTSTART'
property. this would relax all locations where clients need to access
different names for an identical property.

2) move 'attribute calIDateTime endDate;' from calIEvent.idl to
calIItemBase.idl and remove 'attribute calIDateTime dueDate;' from
calITodo.idl. events would map this attribute to the 'DTEND' property
and todos would map it to the 'DUE' property.

3) move 'readonly attribute calIDuration duration;' from calIEvent.idl
to calIItemBase.idl and provide the implementation at calItemBase.js.
this is necessary since events as well as todos need to provide a duration.

this essentially would leave us with an empty interface for calIEvent,
which would suggest to get rid of it and rename calIItemBase to
calIEvent and inherit calITodo from calIEvent. but this seems a bit
strange to me and i'm not sure if this would be the right approach.
maybe this idea is a bit too radical.

but all the other modifications mentioned above would help to streamline
the implementation of the backend as well as the frontend and therefore
would help avoiding problems with this conditional property hassle.

any thoughts on this?

mickey.

[Daniel Boelzle]

Hi,

some comments inline

> 2) move 'attribute calIDateTime endDate;' from calIEvent.idl to
> calIItemBase.idl and remove 'attribute calIDateTime dueDate;' from
> calITodo.idl. events would map this attribute to the 'DTEND' property
> and todos would map it to the 'DUE' property.

I think this complicates semantics with a todo's COMPLETED date. One can
ask why endDate isn't mapped to COMPLETED.
Supporting your approach to handle items easier (and thus supporting a
cleaner fix of your current issue), I would favor to move
calIEvent::endDate to calIItemBase::endDate, but keep calITodo::dueDate.
calIItemBase::endDate would map to a todo's COMPLETED (if set) or DUE.
That way, dueDate and completedDate stay clearly defined.

> this essentially would leave us with an empty interface for calIEvent,
> which would suggest to get rid of it and rename calIItemBase to
> calIEvent and inherit calITodo from calIEvent. but this seems a bit
> strange to me and i'm not sure if this would be the right approach.
> maybe this idea is a bit too radical.

We would loose the ability to add stuff meant for events only. IMO even
an empty interface makes sense here: it tags the object being an event.

-Daniel