A few months back I wrote about my quest for a new iCalendar library for Ruby. I’ve continued work on it, and it should be ready for its initial public “offering” in a day or two.
I’ve applied for a Rubyforge project called rical (for Ruby iCALendar, although I’d prefer that it be pronounced RICK AL), other than that, I’m waiting for Adam Wiliams who has been using a private pre-release copy and has been pestering me to release it for some weeks now gives it another “smoke test” and some additional rspec examples if he finds any smoke.
I’ve made progress on a couple of fronts since the last report.
Although occurrence enumeration was reasonably fast there were a few use cases which were noticeably slower. Unfortunately these tended to be those heavily used in the recurrence rules typically used in time zones, ones which occurred just a few times in a large period, like every second Sunday in March at 1:00 A.M. I’ll probably write about why, and the odyssey of re-factoring which ensued in a later post, but suffice it to say, I’ve got a brand new design and implementation of recurrence rule enumeration which is significantly faster. The old implementation ran the entire spec suite, including all of the use cases in RFC 2445 in 15+ seconds on my late 2008 white MacBook, the new implementation runs a slightly larger suite in less than 5 seconds.
Adam hasn’t been using enumeration (yet, I hope he will soon though). His motivation was solving problems first in parsing icalendar input from other calendar apps using the existing Ruby iCalendar libraries. The VTIMEZONE support in rical is a big help here. He found a few deviations from RFC2445 which rical used to share with the icalendar and vpim gems, but doesn’t anymore.
Adam’s next need was proper exporting of RFC2445 output, which until then was lightly implemented. He also prodded me for a builder DSL for creating calendars and calendar components similar to that in the existing iCalendar gems. He offered to work on that this weekend while I focused on exporting. But two things changed the plan. I got the exporting done rather quickly, which was lucky because his wife’s OB/GYN apparently decided that she needed to deliver a new son via caesarian right now! So I went ahead and did the builder DSL myself.
Since the dead tree version of 3rd edition of the Pickaxe showed up in my mailbox on Friday, I decided that it might be good to work on making the library Ruby 1.9 compatible. So I started on that Friday night, and with lots of interruptions, including spending most of yesterday at a Radiant sprint, just finished a few minutes ago. Rical runs fine on Ruby 1.8.6, 1.8.7 and 1.9.1
So barring any surprises from Adam’s explorations, rical should be published soon after I get approval from Rubyforge for the project. I’m also planning to push it to a new github repository under my github account to keep the ‘edge’ version.
I’ve tried to keep rical ‘pure ruby’ and not Rails specific, although it should play well with Rails. In particular it will pick up timezones from ActiveSupport enhanced Ruby Time and DateTime objects using the TimeWithZone stuff which arrived in Rails 2.2. After things settle down a bit, I’m thinking about starting a Rails plugin which will exploit rical and ActiveRecord to help store calendar components in the database.
Although it would have been nice to have more billable time which would have meant that rical might not be quite as ready to ship, I’m looking forward to giving it more exposure, so far I’m pretty happy with it and I hope that others will be as well. Adam seems to think some will.
Watch this space.
Trackbacks
Use the following link to trackback from your own site:
http://talklikeaduck.denhaven2.com/trackbacks?article_id=547
-
Well, "a day or two" turned out to be a little more like a week, and the official release is still a bit in the future, but I've just published an unofficial version of ri_cal on github. I've been working with Adam who is using github for a Rails ...





Looking forward to seeing this code released. I’ll watch here for a new blog post, but if I follow your github repo is that where we’ll first see the code?
Wes,
Well, as I just posted to the blog. I just released an unofficial version to github. There are still a few things to be polished before I consider it really ready. The official release will be on RubyForge with Github used for interrim versions