[chandler-users] [possible bug] Problem with ICS file import
jeffrey at osafoundation.org
Fri May 30 17:29:38 PDT 2008
> I see now. Well, there's no good way to check whether something is a
> valid iCalendar, or not since the only on-line validator is, as you say,
> too benevolent and all the other language parsers process the stuff
> without a problem. This is quite frustrating, isn't it?
Indeed. iCalendar interop is such a fraught topic that various
organizations (including OSAF) got a trade group called CalConnect
going, one of its main purposes was to move forward iCalendar interop
Sadly, Palm doesn't come to the interops :)
BTW, our Python library for iCalendar *does* do rudimentary validation,
not just parsing, so I suppose someone could write a webapp using
vobject to do slightly more than the ical4j version does.
> I would rather suggest to implement an extremely benevolent iCalendar
> parser for any PIM tool which really would require only a very core
> subset of entries to be filled correctly.
Well, the thing is, the parser is fairly liberal in what it accepts, it
parses your file fine.
The problem is that those UIDs have a lot of semantic importance, we do
a mapping between the iCalendar version of an event and our internal
version. It just literally hadn't occurred to me that we'd see this
particular kind of invalid iCalendar (no UIDs).
Now that I know this is out there, it's easy to fix.
> Another suggestion would be to better report (at least in the logging
> window, if not the import dialog) the cause of problems. I do not mean a
> complete diagnostics, but at least a line number in the imported file in
> which the error occurred would help a lot with debugging and
> investigating what might be wrong with my data. With the current
> reporting, I am left in dark regarding my data. Even the import progress
> bar went to approx. 30% and it takes several seconds to process the
> file, so I think the problem is actually somewhere later in the file
Heh. I've had a bug on my plate for a long time to improve import error
messages. I actually did implement line-number reports for parse
errors, but as I mentioned, your first problem wasn't a parse error.
> Thanks. I will give it a try. Actually I did the same in Ruby/icalendar
> gem and I am attaching the resulting file (which has UID filled!). But
> that cannot be imported to Chandler either, though the reason is a bit
> different (anyway I am in dark regarding the actual reason - is the FREQ
> field somehow wrong?).
I don't know much about the Ruby library. That error is pretty strange,
though. Unfortunately you didn't attach your ruby-generated file,
please do send it on, I'd like to figure out what's going wrong, it
looks like a bug I haven't seen before.
I tried the Python route with the original file you sent and it imported
> So does this mean that even the Ruby serialization routine is broken? I
> mean what should I do if there's no single correct implementation of
> this funny format as it seems...
Unfortunately UIDs are really the simplest thing that can get screwed up
with iCalendar, timezones and recurrence are the real problems. It
wouldn't shock me if the Ruby library's doing something unexpected with
More information about the chandler-users