One .ics file per event being created
After quite a bit of playing around, I finally have CalendarServer running and both my iCal (Mac OSX) and Lightning (Vista64) reading and writing to the same calendar. The next part I am trying to implement is a web interface. I am trying phpicalendar, but it exepcts each calendar to have one .ics file. However both iCal and Lightning are creating one file for every event. Are they suppose to be doing that? -- View this message in context: http://www.nabble.com/One-.ics-file-per-event-being-created-tp16515799p16515... Sent from the Calendar Server - Users mailing list archive at Nabble.com.
On 05.04.2008, at 19:19, mikejp wrote:
it exepcts each calendar to have one .ics file. However both iCal and Lightning are creating one file for every event.
Are they suppose to be doing that?
Yes, in fact thats a requirement for CalDAV (only one UID per HTTP resource). Would be nice if phpicalendar would support CalDAV-style calendar folders, but w/o an index DB it would be quite costly. The script would need to touch many files, every time it shows an overview. (it could probably reuse the iCalServer index DB, but then it would be iCalServer specific) Greets, Helge -- Helge Hess http://www.helgehess.eu/
Hi Helge, --On April 5, 2008 7:43:56 PM +0200 Helge Heß <me@helgehess.eu> wrote:
it exepcts each calendar to have one .ics file. However both iCal and Lightning are creating one file for every event.
Are they suppose to be doing that?
Yes, in fact thats a requirement for CalDAV (only one UID per HTTP resource).
Would be nice if phpicalendar would support CalDAV-style calendar folders, but w/o an index DB it would be quite costly. The script would need to touch many files, every time it shows an overview. (it could probably reuse the iCalServer index DB, but then it would be iCalServer specific)
The best thing would be to make phpicalendar a caldav client. Then they could use e.g. the time-range query report to just fetch appropriate events for display. In fact all they would really need to do is implement that report (to read events) and PUT (to store events) and that would be good enough as a starter. The only real complexity here would be parsing the report response and aggregating the separate calendar components into a form it could easily handle. That kind of depends on the underlying calendar library. -- Cyrus Daboo
participants (3)
-
Cyrus Daboo
-
Helge Heß
-
mikejp