Well, I found the first problem with my exported iCalendar data. In iCal, I turned off everything except my two exported Oracle Calendar views (one done via export/import, the other extracted and published), so I could compare the two. I noticed that my published calendar was not showing recurring events properly. Only one instance of each event was showing up.
Now, I already knew that the CAPI is supposed to export multiple VEVENT records for recurring events, instead of adding RRULE attributes. But I didn’t expect this to be a problem, as I just need the stuff to show up, and I’m not worried about editing the exported data, adding new recurrences, etc. I’m doing all that kind of manipulation via the Oracle Calendar client.
So, why am I only seeing one event? First thing I checked was the .ics file. Maybe the docs are wrong, and it’s exporting RRULEs after all, and I’m ignoring them? Nope… each recurrence does have a separate VEVENT in the iCalendar file. So why aren’t they all showing up? Because they all have the same UID.
So, CAPI does export separate VEVENTs, but it doesn’t make each one a “real” separate event by assigning it a new UID. Kind of annoying. It’s one thing to cheap out and not support RRULE, but it’s entirely another thing when the result doesn’t comply with the iCalendar spec.
Interestingly, the vCalendar export does assign unique IDs to the recurrences. Too bad they couldn’t do it with the iCalendar export. Looks like I’m going to have to do it myself. For my first stab, I’ll just build a hash of UIDs as I’m reading the iCalendar file, and if I find a duplicate, I’ll append an ascending number to the end. Hopefully that’ll work OK. It’s dependent on Oracle Calendar exporting its data in the same order each time. Dunno if it does or not. If not, it means that the recurring events’ UIDs may not be consistent across multiple exports. That may or may not present a problem with the Palm export. I guess time will tell.
Well, off I go to make this happen.