217550 - MozPSU Calendar development plan

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[Mike Young]

after working on bug 188660, we've found a need for further work to make the
calendar robust enough for future development.

See news posting news://news.mozilla.org:119/bhkmc2$[e-mail]

and see the first attachment for our development plan

This bug will be a tracking bug to keep track of the changes we (hopefully with
the help of other developers) plan to make.

Comment 1

[Mike Young]

Attachment: Development Plan

Comment 2

[Mike Young]

I've attached our IDLs to these dependicies of this bug... sorry about how long
this took.

We'd like to hear any comments or suggestions people might have about our plan,
and I'll be posting them to the newsgroup for that purpose as well.

hopefully once we get these finalized, we (and others!) can start coding and
fleshing this out.

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

I'm not sure if this is the right bug, but here we go.

I've been thinking about how remote calendars are handled at the moment.
basicaly, i don't really like it :) The concept of one big file with all events
just doesn't scale. Also, storing in an imap folder or whatever isn't possible.

So, what i think we need is abstraction. First, we need some component that has
a list of calendars.
Those calendars contain a list of events.
It is the problem of the calendar to provide individual events. There can be
multiple types of calendars, like localics, remoteics, remoteimap.

The remoteics type can be an improvment of the current situation. So instead of
getting the file, and putting it back when needed, really have a remote
calendar. Ofcourse, this needs some kind of cache, like described in the
attached document.

The events must implement some interface, which can be oeIICal, like they do
now. But maybe we need some other interface.

Now, the searching of events. Should this be done by the general manager, or by
the individual calendars? I'm not sure. The first option is the easiest, the
second the fastest. Maybe we can start with all searching done at the client,
and then add some simple query to the calendars, like events in a certain range.
That would be the most common anyway. In fact, it is essential for display.

Also, we need some kind of signalling systems, to signal the front-end of
updates to the calendars. This is needed for shared calendars.
The nsIObserver infrastucture might be useful.

I hope I made some sense :)

Comment 4

[Mike Young]

PSU is no longer funding students to work on mozilla :-(

The bugs we were working on (with the exception of bug 188660 are now irrelevant
with the massive backend changes that were made to the calendar.

Resolving.