Create an iCal parser (parser_ical)

Here is the code that we could use for building an iCal parser.

In Date module the iCal logic lives in its own inc file:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/date/date_a...

The hard work is done. What's missing is a parser that integrates this iCal parser with feedapi: parser_ical.module !!!

The parser should create parsed items the feedapi way (see parser_simplepie or parser_common_syndication) - the rest can be handled by a Feed Element Mapper mapper implementation for date fields (see feature request here: http://drupal.org/node/215979).

This is not rocket science, it'll take a developer one or two days to get this up. I am unfortunately swamped with work at the moment, but I would love to see this feature happen and I am ready to give advice to whoever steps up to this task.

Is anyone working on this already? If not, perhaps I can find some time to take a look at it over the next weekend.

I've made something of a start on this - using code from date_ical and the present parsers. It will need some little workrounds to make it work with the date_ical parse to start off with. So I'm claiming this -- *but* if anyone wants to join in, take over, or what ever I'm kinda busy. I just really want it for the continued development of http://drupal.org/node/215979 ;-)

hooray :)

OK, I'm not getting so much time, so this is slow, so I'm going for the release early, release often, and be damned option.

Attached is 'working'.

It has no requirements testing, it has little validity testing, and it's got no install script.

It reuses the parser_common_syndication functions for getting the feed, because they are good, but so has an install issue (you need parser_common_syndications tables already).

It uses the date_api_ical functions for parsing, but has to patch the upload() function as that include the functionality for collecting the feed (which is being done with above). I've mailed karens about the possibility of accepting a patch to separate out the fetching of the ical file and the parsing it but heard nothing yet.

OK, I'm not getting so much time, so this is slow, so I'm going for the release early, release often, and be damned option.

Attached is 'working'.

It has no requirements testing, it has little validity testing, and it's got no install script.

It reuses the parser_common_syndication functions for getting the feed, because they are good, but so has an install issue (you need parser_common_syndications tables already).

It uses the date_api_ical functions for parsing, but has to patch the upload() function as that include the functionality for collecting the feed (which is being done with above). I've mailed karens about the possibility of accepting a patch to separate out the fetching of the ical file and the parsing it but heard nothing yet.

First, thanks for working on an iCal parser, it's a really exciting use-case of FeedAPI!
Well, I suggest you the following:
- You can safely delete the block after // Do the autodiscovery at this level, pass back the real data // Maybe it's HTML. If it's not HTML, not worth to take a look into the downloaded string
- a simple processor, like this, does not need any tables. You can make it even more simple. The caching is just an option.
- i recommend you to simply copy more code from parser common syndication. The problem is that FeedAPI is not dependent on any parsers, they are totally interchangeable.

Can you supply here a "feed url" suitable for ical parser? I would really like to try out the code :)
I attached a simplified version of the module. I haven't tried it out, but it contains my ideas in code-form. :)

Cool I'll have a go with it - I'm just looking at the date_mapper again so I'm going to try with some of the iCal output.

I've been using the index of feeds at:

http://icalshare.com/

to come up with interesting and different iCal feeds.

Hey,

Looks like a good start. I created a patch from ekes and aron's posts here. (for adding new files cvs add all new directories and files followed by a cvs diff -u -N from the feedapi directory, let's use a single patch on this queue for our discussion)

It doesn't work though :( :

When I use webcal:// as schema, there is an error that the feed couldn't be retrieved, when I use http://

I get this error:

Call to undefined function date_make_date()
http://skitch.com/alexbarth/8we7/mozilla-firefox

(feed http://ical.mac.com/ghodder/1st%20Year%20multimedia%20timetable.ics )

In regards to patches to date module files, please go ahead and just post them on the date module issue tracker and link to them from here. I am sure Karen will review them. For simplicity, I think the way you took by copying the code into the ical parser module and clearly marking it as patched is a good method for now.

One request: Can we call this module parser_ical ? I don't know where the common is coming from.

Alex

Call to undefined function date_make_date()

date_make_date is a date_api version 2 function

Can we call this module parser_ical ? I don't know where the common is coming from.

It was only there because it was based on parser_common_syndication, so sure. But, on that point...

- a simple processor, like this, does not need any tables. You can make it even more simple. The caching is just an option.
- i recommend you to simply copy more code from parser common syndication. The problem is that FeedAPI is not dependent on any parsers, they are totally interchangeable.

This isn't a big issue, but I feel I should mention as it feels big in my underlying design brain.

While I agree that the feedapi itself does not want to be dependent on any particular parser. If there are parsers that are coming collectively with feedapi (or in the future just for feedapi) it seems wrong to reuse code by cutting and pasting. There is some good code in the feedapi_common_syndication.

It would be nice to have a common part of the parsers to reuse. Be it just a set of functions and tables.

But like I say it's not that important.

Subscribing.

Also subscribing.

Here is a minor patch to the parser_common_ical module, but more important a patch and new info file that make it work with Drupal 6, in anticipation of rolling out parser_common_ical with FeedAPI's Drupal 6 version when ready.

David

Subscribing

subscribing

Hi.
I have managed to add events using FeedAPI Node and the iCal parser.
Am I correct in thinking that the start date of an event is not updated with the DTSTART value in the ical feed? How would I go about getting FeedAPI Node to store the start time in a CCK field?

Thanks

Subscribing, I haven't had time to try this out, but I'm obviously interested :)

subscribed

http://groups.drupal.org/node/13720

This just came out, not sure if it's useful for you guys or not. Author created a module to take a GCal XML feed and display it in a block.

Subscribing