Parsing iCal Data
by Robert Pratte
|
Pages: 1, 2, 3, 4
This code will produce the following Dot file:
digraph unnamed {
size = "10,7";
compound = true;
ratio = fill;
rankdir = LR;
"5F88A0EC_AD21_428E_AAAD_005F1B1AB72E" [ shape = record,
label = "Set up File Server | <START> Start |
<END> End | Music server for the kids."];
"5F88A0EC_AD21_428E_AAAD_005F1B1AB72E":START -> "20050615T180000";
"BDF17182_CA21_4752_8D4F_40A4FE47C90D" [ shape = record, label = "WWDC |
<START> Start | <END> End | Lots of sessions."];
"BDF17182_CA21_4752_8D4F_40A4FE47C90D":START -> "20050606";
"BDF17182_CA21_4752_8D4F_40A4FE47C90D":END -> "20050612";
// Create tasks relationships
// Create timeline relationships
"20050606" -> "20050612" -> "20050615T180000";
}
Note that this code uses the record shape, holding individual segments within the larger object. This is slightly more complicated than the default oval that Dot uses.
Where to Go from Here
If you are using Apple's iCal application, note that the location and naming scheme of iCalendar files changed between the 1.x and 2.x releases. Previously, iCalendar files went in the ~/Library/Calendars/ directory and had names of the form <calendar name>.ics. Thus, a calendar named Work would have a file Work.ics. However, the 2.x release keeps iCalendar information in the ~/Library/Application Support/iCal/Sources/<calendar name>/ directory as sources.ics.
Other applications that implement the iCalendar specification, such as Mozilla's Calendar extension for Mozilla/Firefox/Thunderbird, may follow a different convention. On a Mac, Firefox stores .ics files in the ~/Library/Application Support/FireFox/Profiles/<profile>/Calendar/ directory, where <profile> is the profile specified in the Firefox profile.ini file. Again, other systems will likely store this information in different locations.
While on the topic of different implementations, bear in mind that, while the key:value specifications are consistent (as long as the application conforms to RFC 2246), the actual .ics file may look slightly different. For example, Firefox lays out that first event from the previous example as:
BEGIN:VEVENT
UID
:b9794c88-1dd1-11b2-bb51-8a92011a78e8
SUMMARY
:Apple WWDC
DESCRIPTION
:Lots of sessions
LOCATION
:San Francisco
URL
:http://developer.apple.com/wwdc
STATUS
:TENTATIVE
CLASS
:PRIVATE
DTSTART
;VALUE=DATE
:20050606
DTEND
;VALUE=DATE
:20050612
DTSTAMP
:20050618T191731Z
END:VEVENT
Here, the key:value tuples (plus any data modifiers such as
VALUE=DATE) almost always split up across lines. In this case, it
would be best to handle this difference when reading in the .ics file, so that
the rest of the script can expect data in a generic format. One way to do this
is to copy the array representing the .ics file using a finite-state machine.
Another method would be to walk the array and join array elements under certain
conditions, such as if the first non-white-space character of the current
element begins with a colon or semicolon character, or is simply
non-alphabetic.
Hopefully, this article will spur you to create a bridge between two of your favorite applications. Good luck, and please remember to share your contributions with the community.
|
Related Reading Perl Best Practices |
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 6 of 6.
- Use CPAN
2005-08-19 05:24:03 DaveCross [Reply]
I'm guessing that this would all reduce to about 20 lines of code if you used Data::ICal (to parse the iCal file) and Graphviz.pm (to generate the dot file) instead of writing your own versions.
It's always worth checking CPAN before writing a line of code :)
Dave...
- re: Use CPAN
2005-08-22 06:13:11 simon@thegestalt.org [Reply]
I can see the reasoning behind showing Perl as a generic glue langauge but, for what it's worth, I knocked up a quick script which uses CPAN module to do the same thing and will work with things like complex recurring dates (the example generated is from the slightly terrifying definition used for london.pm's meeting dates)
You can find the script here:
http://thegestalt.org/simon/perl/ics2graphviz
and the resultant png here:
http://thegestalt.org/simon/perl/cal.png
- Use CPAN
2005-08-19 06:42:34 blech [Reply]
I agree with davorg.
In addition to his point (that using modules saves you writing code), there are lots of strange edge cases that are possible in ICS files (for example, properly expressing the London Perl Monger group's meeting date takes three rules in combination); using a (good) module means that you don't have to think about this sort of thing, because someone else will have done it for you.
Admittedly, finding a good module can take some time (there are several ICS parsers on CPAN: good subject for an article, perhaps?), and sometimes it's OK to have a less robust solution, but in general, it's worth the effort to look at CPAN.- Use CPAN
2005-08-19 11:38:07 RobertPratte [Reply]
Yes, in general using existing CPAN modules has several advantages, reduced coding and access to stable code that has been tested by a large user base among them. I did point to some parsing modules, but perhaps should have included a link to the ICS parsers as well.
The down side to using modules is that the programmer implementing them doesn't always take the time to understand the underlying logic used. Additionally, sometimes the module doesn't work because it hasn't been maintained, or because of dependencies. In fact, my experience with Graphviz.pm has been such - last time I tried to use it, there were some issues. Sometimes it is easier to write something that fits my needs than to get a particular module to do what I need. Of course, had I spent the time with Graphviz.pm, there may have been greater benefit to the larger community.
Regardless, thanks for the feedback!- Use CPAN
2005-08-22 08:52:08 acme [Reply]
As the author of the GraphViz Perl module (http://search.cpan.org/dist/GraphViz) I'm slightly disappointed that you generated "dot" files by hand. I'd love to know (by email) what issues you had with the module.
Cheers! Leon
- Use CPAN
2005-08-22 01:05:01 Oyku [Reply]
As always with Perl, there's always more than one way of doing things. I agree with other folks, but I have to admit I never thought of using iCal with Graphviz,IMHO your article serves its purpose by showing how Perl is intuitive and practical as a glue between rough surfaces.
- Use CPAN
- Use CPAN
- re: Use CPAN




