[kronolith] mcal list events

[John Soward]

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?


-- 
John Soward
Commonwealth Administrators
p: 859.226.1525 e: soward@catpa.com