This is mostly working well but I ran into situations where a valid ical file was parsed correctly but no nodes were saved. In debugging it, it turns out that FeedAPI won't save any node that doesn't have either original_url or guid set and neither of these are required ical fields, so it is entirely possible to have an ical file that ends up with both those values empty. I made a patch to force a value in there so this won't happen.

CommentFileSizeAuthor
#3 parser_ical.200902221.patch932 bytesekes
parser_ical.module.patch1.79 KBkarens

Comments

ekes’s picture

ekes commented

Hmm... interesting.

As far as I can see the UID (which was mapped to the GUID) is compulsory http://www.apps.ietf.org/rfc/rfc2445.html#sec-4.8.4.7 but it does make sense that non-RFC compliant iCal feeds can be read - so some more sensible default than '' will be needed.

What I think needs to be made sure of on creating one for a feed item is how unique it is, because FeedAPI, I believe, stores these and uses them in its duplicates checking. So anything must be unique enough, but not create duplicates? I'll check this though.

karens’s picture

karens commented

True, I should have said it might be missing, not that it wasn't required. My experience is that ical feeds provided by the 'big guys' (Google, Apple, etc) are compliant, but there are lots and lots of feeds created by custom code or whatever that may not be.

Anyway, yes, the idea is just to make sure *something* is in there, I was assuming the title would be unique, or fairly unique, but that may not be save to assume. The only other value that I think you can count on would be DTSTART, so maybe something like the subject plus the date, or a hash of that value, would work.

ekes’s picture

ekes commented
StatusFileSize
new parser_ical.200902221.patch932 bytes

Yep, I was thinking a hash (just in case) of dtstart and summary - as attached. I'll pop it in CVS in a bit, unless someone spots something I missed.

howartp’s picture

howartp commented

Ekes,

The only problem with a hash of the dtstart and summary is when the event start time changes, which is (certainly for us) the usual reason for an event changing.

However I don't know what a safe bet would be for the hash either :(

Peter

ekes’s picture

ekes commented
Status: Needs review » Needs work

Hmm... we need to uniquely as possible identify items, but want to avoid anything in that item that might change if possible.

The start date can change, but it still be the same event. So maybe SUMMARY alone is just the best it can be.