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.