See subject. I checked the API documentation, and it has a complete list of iCalendar attributes that the server returns. So, in my downloader code I just listed out each attribute except ATTENDEE. With that list of attributes, it took about 1 minute to download a year’s worth of data. When I added ATTENDEE in, the download pretty much ground to a halt.

So at any rate, it looks like I want to leave ATTENDEE out when doing my bulk downloads. That’s a bit of a bummer, though, because it means I won’t get attendee lists for meetings etc. It’d be useful to have that. What about this compromise: for a small window, say today through two weeks from today, I’ll export events with attendees. Then, for events outside that window, I’ll export events without attendees. I think that gives me the best compromise between performance and function.

The only other possible issue I can think of is, the UID field. Each event has a UID field that uniquely identifies that event. I’m hoping the UID stays consistent across multiple exports of the same data. I’m pretty sure the Palm sync stuff keys off the UID, so keeping the UID consistent should make the Palm sync process faster and more reliable. I did try exporting the same date range (all of 2005) twice, saving the results to a file, and comparing the files. The UIDs were the same both times, so that’s a good (although not conclusive) sign.

Next up: I’ll massage the data as necessary and try turning it into an iCal subscription.

I used the Oracle Calendar GUI client to create iCalendar and vCalendar exports for the same date range. The formats are obviously different, but the data extracted is similar. Exceptions: The vCalendar export includes “TODO” items from Oracle Calendar, which I’ve never used and don’t care about. And, the iCalendar export includes email addresses of attendees. I wonder if that’s what’s slowing it down. If the email lookup process is time consuming, it will REALLY drag things down, because our calendar server includes a LOT of entries with many attendees.

Also, earlier I tried importing one of these iCalendar files into Apple’s iCal app, and had problems. It would import one entry and then stop. Upon closer examination, I think I see why this is happening. The exported iCalendar file encloses every single event inside a separate BEGIN:VCALENDAR / END:VCALENDAR block, complete with all the vCalendar headers, etc.! In other words, it’s not a valid iCalendar-format file at all. iCal probably aborts when it sees the first END:VCALENDAR, thinking it’s done.

Anyhow, back to my earlier point, I decided to test my theory that the email lookups are dragging down the iCalendar export. The API allows me to explicitly specify which iCalendar properties I want included in the exported file. So, I told it to include just a small set of properties (start date, end date, summary), to see how it would do. Yep, the export was much faster. Now, I just need to build up the full set of properties I need, omit the attendee info, and see how it does then. Unfortunately, there’s no way to say “I want every property except attendee info.” I either have to request every property, or request a specific list. So, I’ll need to look at the iCalendar spec, get a full list of properties, and explicitly list out the ones I want. Kind of an annoying limitation if you ask me.

The other question is, is there a way to get the vCalendar format through the API? Or, assuming the email lookup is the culprit, can I pull attendee info without doing the email lookup? Dunno, but I’m getting a little ahead of myself here.