[kronolith] mcal list events

Jan Schneider janmailing@gmx.de
Tue, 17 Jul 2001 19:04:35 +0000


Zitat von John Soward <soward@soward.net>:

> Jan Schneider wrote:
> 
> > Zitat von Chuck Hagenbuch <chuck@horde.org>:
> > 
> > 
> >>Quoting Jan Schneider <janmailing@gmx.de>:
> >>
> >>
> >>>How about changing this behaviour?
> >>>If only I knew someone of mcal's developers... :-))
> >>>
> >>Heh. Most of the core mcal code is stuff I haven't had a chance to pick
> apart
> >>
> >>yet... how do you feel about starting on a sql.php driver 
> >>(Kronolith_Driver_sql)? The abstraction is there, at this point, and I
> think
> >>
> > 
> > Now that we have a starting point, this is a really good idea!
> > 
> > 
> >>not requiring MCAL would be a nice step for us.
> >>
> >>That said, post to the mcal list, and remind me, and I might be able to
> look
> >>at 
> >>it at some point. I don't know what the logic behind that choice was.
> >>
> > 
> > I just took a look at the mcal sources and as far as I know the problem has
> its 
> > reason in calevent_next_recurrence. This function searches for the next
> start 
> > date after the search date (*first). A quick fix would be to search for the
> 
> > next end date and checking if *first is between the start and the end
> date.
> > But as I don't know C I'm not able to do this change.
> > 
> > I saw another problem: search_alarm doesn't look for recurring events at
> all. 
> > Perhaps we really shouldn't invest any time into mcal and put the focus on
> the 
> > new sql driver...
> > 
> 
> 
> Mcal's def got some prob...but the idea of it generating iCal or iCal-like
> files 
> 
> that might possibly one day maybe be able to be exported into other iCal 
> reading things (like PDAs) -- and that maybe similarly one could import 
> iCal like stuff into it from other calendars, or even talk to a 
> 'calendar' server (icap) once that stuff firms up -- anyway, that idea 
> is really appealing.
> 
> But if not much is going on with mcal, then maybe a better approach 
> would be to use a local DB and come up with some import/export routines?

Import into kronolith is halfway done. It will import csv and ical files. 
Exporting will be the next step.

I agree that there must be a lot work be done in mcal if it doesn't want to 
become obsolete.

Jan.