Re: Proposed changes to Calendar abstraction

[Miguel de Icaza <miguel gnu org>]

> 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.)

Not really.

Let me exaplain, the only thing we should care about is the "Calendar"
interface.  This is an opaque data structure and we can make it an
object, so that we have various methods for different
implementations. 

calendar_load and calendar_load_from_vobject are just factory
functions: they create Calendar objects on demand, but the code in the
gnomecal does not care how the Calendar object was created.

> 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 would like it to be called:

  vcalendar_calendar_XXX

> I think that will be a much more sane abstraction and 
> code division as the number of calendar types increases.

Sure.

> * 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: 

Why do you want to have more than one Calendar in a GnomeCalendar?  I
am curious.  

Because, to watch another calendar, you just open a new window with
the calendar.  And we do have a user interface (that I hope Damon
commits soon) for doing free-busy scheduling of multiple parties.

> 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.)

best wishes,
Miguel.