?

Log in

No account? Create an account

Tue, Nov. 13th, 2007, 04:39 pm
All Tomorrow's Parties

After my last bit of Calendar fiddling I was left slightly disgusted by the state of the code. In my defence it was written over the course of a hungover Sunday afternoon but there was CGI and DBI code mixed up together, no DBI place holders and all sorts of other perversions and sickness. At least it was all templated, which is something.

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.