So I ripped out all the DBI code and put that in an abstraction layer and did the same for the handling stuff and then just generally had a cleanup which also ended up with it gaining a config file rather than hardcoded values, marked everything up as hCalendar and made it multiuser in the process.
Because the DBI stuff was abstracted out it was pretty easy to add another provider which could read from iCalendar files both locally and remotely. To be honest, I was vaguely shocked when I plugged in my Dopplr feed url and lo and behold my trips showed up.
So far so good. A neat, tidy, clean and simple to install calendar system that, whilst it only has the concept of all-day events, can read and export iCalendar (and copes with recurring events through that). Although I've also got code lying around for a more complicated calendaring system I've been using this system for the last 5 years and it works just fine.
Two small bug bears I'm wrestling with. The iCalendar exporting is fine but I'd like to make it more flexible to output different formats, it's all a bit complicit at the moment.
I'd also like proper caching. Oddly enough with this it's not the caching code that's the problem - it's the config file.
Well, sort of. In concept it's very simple. At the moment we have two types of provider: DBI and iCalendar. Actually, if we look skewiff at it then we have 3 types: DBI, iCalendar and the one that takes the input from multiple providers. A cache would just be another provider and either sit after the multiple provider or in between the multiple provider and one of the other providers (probably a remote iCalendar provider since local iCal and DBI are fast enough).
So far so easy but I'm trying to think of an easy way to shim this into my config scheme which is currently .ini file based and looks something like
[providers] default = dbi birthdays = ics dopplr = ics [default] dsn = dbi:SQLite:calendar user = username pass = password [birthdays] # local file file = birthdays.ics [dopplr] # remote url file = http://dopplr.com/user/uid.ics
I'm also not in love with the fact that providers' names are in there twice. I have pondered something like this
providers = default birthdays dopplr [default] dsn = dbi:SQLite:calendar user = username pass = password type = dbi [birthdays] # local file file = birthdays.ics type = ics [dopplr] # remote url file = http://dopplr.com/user/uid.ics type = ics
And then I could change it so that
[simplecache] cache_dir = .cache [dopplr] # remote url file = http://dopplr.com/user/uid.ics type = ics cache = simplecache
which is doable but involves more complicity and blurs the abstractions since some classes are treated differently.
It's kind of vexing that it's not the coding that's the problem, it's designing a clean architecture. It really interrupts your rhythm.