Proposed changes to Calendar abstraction

[rms39 columbia edu (Russell Steinthal)]

Gnomecal hackers:

I've started coding the iCalendar code, and it seems to be going 
well, at least so far.  I do, however, have some thoughts about 
changes which I think would make sense in our Calendar abstraction, 
and would like your comments:

* The load/save interface

Currently, we use functions like calendar_load and 
calendar_load_from_vobject to populate the Calendar, implying 
something of a pull paradigm: Calendar knows about different calendar 
formats and converts the data accordingly.  IMHO, that's backwards.  
If Calendar is part of the central "core" of gnomecal, I think it 
makes sense to have calendar "servers" (here I mean the code which 
knows different formats, such as vCalendar, iCalendar, Lotus Notes, 
whatever) push data into the Calendar.  That way, if someone wants to 
ship addon calendar servers, they don't need to modify the core code. 
 (Plus, if we provide a CORBA interface to calendar_insert_object 
(which I suspect we do or will), we can legally and easily interface 
with non-GPL calendar formats.)

This doesn't require a large change in the code, since 
calendar_load_from_vobject already calls ical_object_create_from_vobje
ct and calendar_add_object to do much of the work.  All I would 
suggest doing is renaming calendar_load_from_vobject into something 
like vcalendar_populate_calendar, ical_object_create_from_vobject 
into vcalendar_create_ical_object, and move them into a file 
vcalendar.c.  I think that will be a much more sane abstraction and 
code division as the number of calendar types increases.

The save interface is analagous and should, I think, be changed 
accordingly.

* The relationship between Calendar and GnomeCalendar

This might make the code more complicated (and might not even be 
doable), but I think a nice thing to aim for would be changing the 
GnomeCalendar->Calendar relationship from 1:1 to 1:N... That would 
most likely require the GUI code to merge multiple data sources, but 
it would also allow things like selectively including or excluding 
calendars or calendar sources: useful for tasks like group scheduling 
(changing which participants' calendars are imported), selectively 
hiding classes or meetings based on one's mood, etc. :)  (The model 
for this idea is ical, a little Tcl/Tk calendar program.)

Under this model, the code would do something like:

calendar_new()
icalendar_populate_calendar_from_file(calendar, fname)
gnome_calendar_insert_calendar (gnomecal, calendar)

I admit I haven't thought through the implications of this for 
network cases...

Anyway, that's it for now, but I'm sure I'll come up with more as I 
keep coding. :)

-Russell





-- 
Russell Steinthal		Columbia Law School, Class of 2002
<rms39@columbia.edu>		Columbia College, Class of 1999
<steintr@nj.org>		UNIX System Administrator, nj.org