On reading the 2006 QuickStats National Highlights from the Statistics New Zealand website, I am prompted to write...

Dear Statistics New Zealand,

In the "2006 QuickStats, National Highlights" document available from here:

http://www.stats.govt.nz/census/2006-census-data/national-highlights/

On the final page is a link to the Excel viewer which would supposedly enable me to open Excel files.

Firstly, the link does not seem to work. When I click on it my browser opens at the location:
http://wipe04/NR/exeres/727CCC9A-22D0-4E71-960B-D72260540535.htm?NRMODE=Unpublished&WBCMODE=PresentationUnpublishedPreview#excel


Which my web browser (correctly) assures me is not a valid domain name. You might want to correct that.

Secondly, the "Excel viewer" is only a solution for those people using Microsoft Windows or Apple Mac OS X. People using other operating systems such as Linux will not be able to install or run the "Excel viewer" application.

A better solution would be to provide a link to OpenOffice.org which provides a fully functional spreadsheet program that is capable of reading such files, and which is:

• freely available
• freely redistributable, and
• will work on a much wider variety of operating systems

Many thanks,
Andrew McMillan.

Actually I remember filling in that Census form online, about a week before the census, leaving out the questions that related to the night itself. Then on the night I discovered that I had already done it, and could not go back and add the answers to those questions.... Oops!

And when I try and post this as feedback to the stats website, I find that:

Server Error in '/CmsApp' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>

Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.

<!-- Web.Config Configuration File -->

<configuration>
<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="mycustompage.htm"/>
</system.web>
</configuration>

Man, I sure wish I could change that file and help them out with that little problem. I know: I'll send them some feedback, telling them! Yeah, that'll help...

At Catalyst, when there were only 15 or so of us in the office, we used to have a running joke about clients saying "I would have thought", where we would use that phrase to introduce progressively more ludicrous requirements, because we had the occasional client who used that phrase to get work done which had not been written into the contract.

"I would have thought that a system for finding computers on an international network would give some thought to that majority of the planet who don't use the english alphabet.¹

Yeah, sure. That'd be simple, right?

Of course such a phrase really indicates that whether they did (or did not) actually think of that requirement at the time, they certainly never documented it. Either they did think it, and simply assumed that everyone knew their business like they did (and we've all been guilty of making that assumption). Or they didn't.

The joke got to a point where we occasionally found it difficult to contain our giggles whenever a client actually came out with it, and for me at least that continues to this day.

As 'in' jokes go, it was an extremely valuable one to have around though, because it made us notice those points where clients were wandering away from the specification, giving us a decision point where we could clearly either acknowledge our failure to identify the requirement, or to argue whether such an assumption should have been reasonable for us to have understood, and so forth.

I'm reminded of this today, when I read RFC2445, in particular it's definition of PRIVATE vs CONFIDENTIAL.

The document does not give a lot of clues, and seems to trust in the meaning of those words to define which is stronger.

My initial inclination was to go with the ordering of the terms: PUBLIC => PRIVATE => CONFIDENTIAL. That, I thought, seems reasonable. In all the movies the nearly secret stuff is all stamped "CONFIDENTIAL", and then stuff gets stamped "TOP SECRET", and in such movies I'm sure that "PRIVATE" is reserved for signs on doors, rather than on secret files.

I immediately had to reconsider, however, when someone else from the other side of the world (literally) decided that PRIVATE should be the secret stuff, and CONFIDENTIAL was merely "somewhat secret". A small bit of googling suggested that I could well be in the minority on this one, so I will adjust my worldview, correct my software, and possibly even stop watching such silly movies.

Still, I thought it would be nice to deliver these conclusions in the place where they belong: right there on RFC2445. Sure, I could write to the authors and berate them for their wishy-washy language:

"... The access classification of an individual iCalendar component is useful when measured along with the other security components of a calendar system (e.g., calendar user authentication, authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications cannot be completely defined by this memo alone. Additionally, due to the "blind" nature of most exchange processes using this memo, these access classifications cannot serve as an enforcement statement for a system receiving an iCalendar object. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar component."

Oh how very fucking useful. This is supposed to be a specification! The intention of my friend from France when he says "PRIVATE" clearly differs from my own, but that can't easily be arbitrated without a frame of reference which the standard should, in theory, provide.

After I calmed down a bit I was reminded of how some software that I use allows people to annotate the manuals, clarifying things, providing examples and so forth, which I have found incredibly useful from time to time, and it made me wonder whether a site that allowed people to generally annotate RFCs (or other documents) could also be useful.

So: do you think it would it be useful to have some room for interpretation?

¹ That one is not a quote, by the way - I have a very good idea of exactly how much debate has gone on around that, and how stupidly complex the issue has become.

I just downloaded a trial version of one of the latest version of the Progress OpenEdge database because of one of those applications I wrote in different days, and which I am unfortunately stuck maintaining.

<RANT>

I find it astonishing that a database which has been operating on a Unix environment for close to twenty years will install itself in a directory tree where:

• Every directory is mode 777
• Every single file is marked as executable

I am nearly speechless. No wonder their market share has sunk so low that they can only claim 60,000 customers world wide.

As databases go Progress is just fine, of course, and we use it for one notably mission critical application in particular (though probably not as significant as some of our larger PostgreSQL based applications).

Just make sure that you "chmod -R go-w ." in the directory you installed it into as soon as possible...

</RANT>

Meanwhile, I guess I'm putting off figuring out whether the newer version will work OK with my 'favourite' 10 year old application, so I better get back to it.

I've been trying for a long time to find something that will match my music needs, but I think I give up, so I have finally decided to release my "Adorno" music server out into the big blue room.

Some people suggested Amarok, but while it does have some web interface plugins they really are Teh Suck(tm) for all-the-time use. Using Amarok over an SSH connection seems to soak network bandwidth to the max, as well, and is quite sluggish. Amarok is nice, but I don't play my music on the computer in front of me.

I looked at SlimServer, but it requires me to run some Java doohickey on the music player which (surprise, surprise) expects the server to have a GUI.

I looked at MPD as well. This is probably the closest thing to something I could use, and if I hadn't already written my own music server years ago I would probably go with this. As it is I have something which kind of works, and which has records of the last 20,000 odd tracks I have played. It only really has a few bugs, which are minor enough to have not been fixed for a couple of years, so I should just get stuck in and do the work.

What crystallised this chain of thoughts for me was yesterday, when everyone got a wee bit excited about the Catalyst IT group on last.fm I decided to finally sign up for an account on there. Of course if I had an account, I had to have some way of actually putting my playlist on there...

... 10 minutes later I had managed to find the Audio::Scrobbler library, and an hour later I had hacked the support for it into Adorno. Looking through the code of the music daemon component of Adorno I realise it ain't that bad. There are a few improvements it could do with, but the basic approach works just fine.

So I'm now listening to Charles Mingus, and it's all being scrobbled up to (by?) last.fm, although I guess strictly this isn't all going to be my choice of music. Under pressure from one of the shorter members of the household I have been known to play "The Wiggles", "Buzz O Bumble" and other stuff I am heartily sick of, but which he continues to adore.

So now I had firmly committed to releasing my code, I had to get rid of the revision control on there (I was using Darcs, since that's the project I was starting when I wanted to try Darcs out) and replace it with Git. I don't think there is any value in retaining all my old history so I just moved the _darcs directory out of the way and "cg-init" in the root of the project.

Then back on my laptop, I just clone from the remote project root and start editing away. Eventually I decide to "cg-push" and my changes go back into the project root on the music server. Except, of course they don't: they go back into the .git directory in there and when I ssh in and run cg-status in the project root it wants to undo all my good works! I think that's a bad Andrew for even thinking of doing something so stupid! So I'm now using "cg-reset" to put my code into operation on my music server. Ouch!

Oh well, I guess that means that Debian packaging must be early on the list :-)

I just found some blogging by Lisa Dusseault on CalDAV and discovered that CalDAV is now a 'Proposed Standard'. That may not mean much, but remember that IETF eventually ends up calling these things "Request For Comments". Lisa and others have spent considerable time and effort developing their specification to this point and congratulations are definitely in order.

So: what's interesting about CalDAV?

People have been asking me why calendaring, and in particular CalDAV, is such a hot button for me recently. The answer has evolved over time, and really comes in several parts...

Firstly, my desire for this is not recent

Shared calendaring has been a "black hole" in the Open Source universe for way too long. Several employers ago (in the early '90s) when I worked for ${LARGE_GOVT_DEPT} I used to schedule meetings using ${GROUP_CALENDAR} and it was damned useful. Later I moved on to work for a much smaller organisation, but ${GROUP_CALENDAR} there was still extremely useful - just in a very different profile of use.

When we got together and started Catalyst IT in 1997 I started turning my back on the 'Windows' world, looking at Linux as something that was interesting and Open Source as a movement I wanted to be involved in.

In 1998 I switched full-time to using Linux on my laptop, but in doing so I denied large chunks of application space which simply wasn't available. Heck, my desperate search for a decent open source word processor caused me to be cited in a 'why the concept of XML documents should not be patentable' recently since I really used some early versions of AbiWord to write letters to clients, and I still had them on my hard disk!

Since then I have seen the application space on Linux slowly populate with great programs that do large chunks of what I want to be able to do with my computer. I've contributed to that too, in programming small applications, filing bugs, promotionally and in other small ways.

So Why CalDAV?

After a while people started to talk about DAV, and perhaps this would be a way of providing a group calendar application. Unfortunately the way it ended up being used by most of the applications that did support it was to use it as a place to dump a person's entire calendar as a single file, or maybe just their free/busy time.

That ends up being flawed in a whole bunch of ways: how do you delegate responsibilities among people, for example?

Although DAV evolved over time to answer some of those questions, the applications that were paying lip-service to DAV failed to evolve in step.

A Star is Born

In the calendaring firmament, at least! Lisa Dusseault started to produce specifications for calendaring extensions to DAV and then she got a job with OSAF specifically to do that. That standards development process has taken three years, but we're finally near the end of it. Here's the description of CalDAV from their website:

"CalDAV models calendar events as HTTP resources in iCalendar format, and models calendars containing events as WebDAV collections. This allows users to publish and subscribe to calendars, share them collaboratively, synchronize between multiple users and synchronize between multiple devices.

Which is an excellent conceptualisation of what is (was) needed.

Meanwhile I was still looking around for a solution to the group calendaring problem, and not just for myself: Clients were also regularly asking what could be used to provide them with a shared calendar solution, and if they were asking me that then they were looking for an open source answer.

Now we have a standard, where are the implementations?

At this point it kind of becomes "chicken and egg". There are no servers, so people can't easily test the clients they are developing, and there are no clients, so people can't easily test their servers. Well a few people are working on these things, of course. On the client side, Mozilla is adding CalDAV support and CalDAV support snuck into Evolution in late 2005. Cyrus Daboo (one of the other authors of CalDAV) implemented it in his 'Mulberry' free-but-not-yet-open-source application, and there are a bunch more which are associated with client-side projects as well.

Looking around though, it seems that there are no simple servers. Some of the servers that are being written seem likely to fall into the trap of working best with their own client application, or they are simply proprietary solutions. Or they have requirements that are (to me) not particularly desirable, such as being written in Java.

I don't have a problem with Java, per se, but when you might want to run 20 applications on one server it always seems to want to get bloated and to eat administrator time...

Hence the Really Simple CalDAV Store

Eventually I got fed up with looking around the open source landscape every few months, searching for group calendar servers and finding the continuing promise of jam tomorrow, but no jam today.

Around May this year I decided to build my own, and around 4th of September I finally had enough answers to start work on it.

Yesterday I made a significant milestone release, with support now for multiple languages in the administrative interface, delegated permissions are working in a basic manner and the CalDAV operations used in Mozilla Calendar and Evolution are fully supported. Most of the CalDAV operations in Mulberry are supported too, although some of the more arcane ones will be my work for the coming month.

Thanks!

Thanks to Cristina, Lorena and Guillaume for their help in translating the administrative interface. I hope to thank a few more people for more translations soon also!

And also, thanks to Lisa, Cyrus and Bernard and everyone else who was involved in making the CalDAV idea a reality. Great work.

Just before I went to the Sydney Moodle Conference I set up a sourceforge project for the Really Simple CalDAV Store. This is good because it disassociates the project from Catalyst to some degree as well as providing me with space for forums, bug tracker and so forth.

It's interesting to look at Sourceforge from this viewpoint though, because I wonder how lively sourceforge really is. According to their home page they have "Registered Projects: 132,439 Registered Users: 1,421,324", but after a few days activity with my RSCDS project I have managed to surpass 132,319 of those projects to be at number 120!

Is it really that easy to be more active than those 132,000 projects? It would seem so. Penny, Martyn and Nigel have also set up a project last week for the Mahara ePortfolio which they are working on, and at this point there is almost nothing there at all. Even so, that project is ranked at number 18,000 or so, suggesting that there are around 110,000 projects on there which are basically dead.

Still, it seems that it might be something to do with their weighting algorithm. I took a look at the statistics for Project #121 (Sahi at the moment) and it seems to have a noticeably greater number of web hits, downloads, and so forth, so I can only conclude that my secret weapon has been my mirroring of my Git repository into the Sourceforge CVS and Subversion repositories.

Well, to be strictly correct, I guess only the mirroring to the Subversion repository counts, since there are no statistics available for the CVS repositories it seems unlikely that they enter the mix in this way. So with that in mind I feel I should level the playing field and publish my mirroring scripts.

So here they are, for mirroring from Git into a CVS repository use cvs-mirror-git-init first and then use cvs-mirror-git whenever you want the mirror to be brought up to date. Hopefully the 'usage' information is sufficient to describe the care and feeding of the CVS mirroring scripts.

For mirroring from Git into a Subversion repository use svn-mirror-git to bring the repository up to date. Before using it you need to do something like:

mkdir newproject
svn add newproject
cd newproject
svn propset svn:ignore .git .
svn commit

to create yourself a new empty directory for the project to exist in.

My Really Simple CalDAV Store moves on apace. I have rewritten several of the libraries to use a more consistent structure, and have now implemented a fair subset of the PROPFIND command - to the extent that Mulberry now works with it as well as Sunbird/Lightning and Evolution.

I've also started developing a regression testing framework, and I believe that the database structures around the calendar resource data are now basically correct. From this point I will provide patch scripts to allow upgrade of resources.

It is interesting to see the different approaches that client software has taken to dealing with CalDAV, and I have to think that this has something to do with the long process of evolving the specification. It will be nice when it is complete, and people can develop against something that isn't moving. I believe that the CalDAV specification is actually quite good and straightforward, but I don't feel nearly as happy about the iCalendar spec.

The iCalendar definitions of timezones, on the other hand, have to be one of the best examples of overachievement out there! It is not surprising that none of the software I have come across actually includes more than the most recent timezone definition information within events. The full definition of the New Zealand timezone comes to around 15k, and it would be ridiculous to include that with every event! In an even more bizarre twist, there is no field within the VTIMEZONE which references the timezone with a standard name! No doubt that is not problematic when most people are arranging things within a timezone, but for global events it really is a significant flaw. Evolution uses an X-LIC-LOCATION property to reference the Olson timezone name, which seems to be an industry standard of sorts, but the standard should define such a thing. Even better, having defined a standard way of referencing the timezone name there would be no need to schlepp the full timezone redundantly along with every event.

Well, enough ranting :-) Improvements in this version of RSCDS include:

• Fix some bugs in caldav-REPORT, which was not working with Lightning.
• Complete work on PROPFIND so that Mulberry now works.
• Add MKCOL, which is based on MKCALENDAR, to support hierarchies of collections better.
• Rewrite REPORT to use the new XML libraries.
• Commence support of relationships and permissions.
• Write new ics.php which allows export of the full repository (for an admin), or a subset of the repository.
• That new ics.php allows webcal presentation of the calendars also, so that even if evolution can't support tasks as CalDAV, it can at least refer to tasks someone else puts there with (e.g.) Sunbird.
• Started development of a regression testing framework.

I think I'm now at a reasonable stage to have a Debian package repository for this project. Anyone interested can browse the Git RSCDS repository or Andrew's Web Libraries repository to see my progress in more detail, it's still better to provide a place where it can all be downloaded from, so you can now add this to your sources.list:

deb http://debian.mcmillan.net.nz/debian unstable awm

For those unenlightened folks running on systems that aren't based around the Debian packaging system I've provided some .tar.gz files for RSCDS and AWL that you can download as well.

I wonder if Windows Genuine Advantage will be used to ill effect by the next round of viruses affecting people who pay their Microsoft tax. That would be bad. I sure do hope that their anti-malware-ware is up to that sort of thing.

Of course viruses have been rewriting registry values and updating bits and pieces of the various Microsoft operating systems for some time now in efforts to disable antivirus software. Surely they will leap at this straightforward opportunity to deny Microsoft customers those updates that might remove the very vulnerabilities the viruses need for their survival.

Catch-22 indeed!

I've updated my simple CalDAV store in some (incomplete) efforts to support Mulberry. Unfortunately it seems that Mulberry is built to support CalDAV before the spec was written, so it goes more for the "DAV" end than the "Cal" end. It has got me to add support for PROPFIND and MKCALENDAR requests though, and I can add calendar entries in Mulberry and have them show up in Evolution. I just can't seem to persuade Mulberry to ever request the events from the Calendar, or even a list of them.

I've also done some work on the user administration side so now it should be possible to create users, set passwords and so forth in these screens. The database structure has not really stabilised yet, and I haven't provided any conversion scripts for it yet.

If you plan on using this for real data, please get in touch with me so I can start providing conversion scripts sooner. I think I am probably one release away from that, so after the next release I plan for the database to be 'roughly right' and I will provide patch scripts for database changes from then.

In case you are interested in sending me fixes or something the code is also available via Git at:

http://git.catalyst.net.nz/gitweb?p=rscds.git
http://git.catalyst.net.nz/gitweb?p=awl.git

Enjoy!

I know that I gave a list of goals for my "Really Simple CalDAV Store" (RSCDS), but of course I did something completely different...

Well, maybe not completely different. One of my goals was to "find some non-Evolution CalDAV clients", and I found Thunderbird + Lightning in the form of a nightly build which worked in many ways. What it definitely did do was point up some of the over-simplification I had taken in my first cut, so I went right back to basics and redesigned tables, renamed columns and rewrote objects.

Another thing that I did, which provided a good bunch of background information was to add CalDAV support to WRMS. This was an incredibly useful thing, because it familiarised me further with the structure of iCalendar entries and so forth, and although the implementation is not really usable, it shows me the real value of storing the iCalendar entries natively and keeping the parsed values separately. That's the way that RSCDS does it, and it seems to work very reliably.

I also did at least start to develop the admin interface, and to improve the database setup scripts. I just didn't get incredibly far down this path, although I probably will now that I've got what I consider a releasable starting point.

The first of the files below is a Debian package of my standard web libraries, libawl-php, which is a bunch of useful routines I've developed over the years. The other file is, of course, the RSCDS application itself.

Updated 2006-12-19: these files have been removed as they are out of date!

Here arewere some files for you to play around with:

• Andrew's Web Libraries libawl-php_0.4-0_all.deb
• Really Simple CalDAV Store rscds_0.1.4_all.deb

Here are some really basic Really Simple CalDAV Store instructions.

While watching the Test The Nation hosting all go swimmingly I decided to add CalDAV support to WRMS and after wrestling with it for a few hours, I now have rudimentary support for entering timesheets into WRMS using a CalDAV calendar.

Rudimentary means "all of the existing timesheets show up" but also "I successfully inserted a timesheet event by entering something into a CalDAV calendar in Evolution". It doesn't mean it's stable, and particularly it's not stable when editing pre-existing timesheet entries. It also doesn't implement permissions much yet, other than ensuring you can only muck with your own timesheet.

So it isn't quite ready for real time, but it's given me enough clues that I know what it will look like when I rewrite it tomorrow, or so.

I really hope that entering timesheets through a calendar application will make this easier. I do know that at present the timesheet form has all sorts of issues, and I really hope this should solve most of them.

Some possibly useful features will come for free too. E.g. in Evolution it is possible to move/copy appointments from one calendar to another, so that could also be a useful trick for scheduled events. Perhaps having a shared calendar will mean that (e.g.) a meeting event can be copied into your timesheet.

Well, as long as the meeting summary matches /^wr[^1-9]*([1-9][0-9]*)[ \/-]*(.*)$/im it should work fine anyway... :-)

But now it's time for bed.

Over the last few days of my CalDAV adventures I have been merrily filing bugs. As one might expect, the CalDAV support in Evolution is somewhat immature. The blame for this can scarcely be laid at the feet of the developer: it seems that he wrote this code sometime last year without a working server to test it against! An impressive feat, for sure.

Unfortunately there are things that even the most legendary of programmers will miss, and as a result of that vacuum there are a number of issues that I have been discovering when I do things like "delete all users from my database" or "stop my webserver".

I, of course, am fortunate to have a CalDAV client to test my server on, and all because of this man's work last year. So my job has been much easier. Even with that client's existence I had already stumbled at parsing the specifications. No doubt my server implementation also has bugs, and I am just about ready to look around for some more client implementations with which to break my server.

The joy of free open source software though, is the fact that there is an expected feedback mechanism. I can file these bugs. In most cases the original developers of the software will get involved, and will care. They will often see through the crap in my guesses about the problem, as I know I also do when people make guesses about the proximate cause of bugs in my own software. People will propose fixes, and eventually the work will be done and I will have new software with fewer bugs. On some occasions this process is more efficient than others, but I value it for the ability to communicate directly with the developers themselves. That really cuts out the layers of miscommunication that can happen when you are dealing with a monolithic development process. Of course these people have other lives and committments, but the ownership of free software development projects is frequently so small and focused that the situation generally works well.

Meanwhile the code for my CalDAV server undergoes rapid change. Yesterday evening I renamed all the tables and many of the fields in the database because even after only two weeks they appeared random and stupid. What better time than before anyone else sees the code?

The administration pages are taking shape now and I expect to have some vaguely usable administration screens by early next week. After that, I will look at some usability improvements because I think that the initial version will necessarily focus on functionality rather than usability. Using a bunch of stuff from existing frameworks I at least have pages to browse the existing users, groups and relationships and adding pages to mofidy them should be a small job.

At the moment I am trying to work out how delegation should be able to happen. It should be possible, for example, for a person to delegate the maintenance of one or more of their calendars to a personal assistant. It should also be possible for some calendars to be actively maintained by many people (meeting rooms and other resources, for example). Easy enough to say, but the data model is not sufficiently elegant for my taste yet.

Following on from my adventures with Apple's Calendar Server, Hula and Cosmo I got my A into G and wrote a really simple program to allow storing and retrieving of events via CalDAV.

I've now spent some time writing my "Really Simple CalDAV Store". I've got it to a point where it:

• Accepts uploaded events
• Reports on events
• Handles updates to events
• Handles deletion of events
• Uses "Basic Auth" to identify the user
• Is Debian packaged (in a very basic form)
• Parses the event into a PostgreSQL table

Further goals now are:

• Provide a simple admin interface for users and groups
• Re-present events in free/busy format
• Find some non-Evolution clients to try to handle
• Write a better process for setting up an initial DB
• Re-present sets of events as an iCalendar URL
• Add support for MySQL (no, just kidding :-)

If anyone wants to play with the Debian packages of this "as-is" I will make them available, but at this stage administration is through SQL queries directly against the (PostgreSQL) database.

This morning I was rudely awakened by the sounds of Boowah and Kwalah as my son Fraser decided to get up at around 6:00am on a Sunday morning. He has been doing this for the last few days, and he has been warned...

The final solution was applied this evening

# Enforce time limits on the computer...
* 0-8,20-23 * * * root /usr/local/sbin/timelimits || /sbin/shutdown -h now

#!/usr/bin/perl -w
#
# Enforce time limits on the use of the computer.
#

if ( -f "/tmp/notimelimits" ) {
  exit 0;
}

my ( $sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();

my $useful = $hour * 100 + $min;

if ( $useful < 830 || $useful > 2030 ) {
  print "Time for a shutdown!\n";
  exit 1;
}
else {
  exit 0;
}

We shall see if it works. At this stage it has managed to shut the computer down this evening, but I think it should work - at least until he can read this page. Perhaps that will be motivation.

This evening Max also restarted his computer after ostensibly being fast asleep in bed, so I was forced to threaten a similar approach. I wonder if these children think that threats are irrelevant until / unless they are followed through on? Certainly, they seem to have no effect, and I have little doubt that I would have felt that way about threats at their age.

Note to self: it appears to be about time to point eldest son at Machiavelli...

Having finally found a working CalDAV server for my current favourite calendar client, I decided to sniff the traffic and see what was wrong with my own protoype server application and it turned out that there wasn't too much to do to get a working prototype. The differences between the Cosmo and Apple Calendar Server were also useful.

What now I have going is a basic CalDAV calendar store which handles:

• Creating an event
• Deleting an event
• Updating an event
• Destruction of the client-side cache

Of course there are lots of things it doesn't do, but it meets my rather simple needs at the moment, and it provides an interesting proof-of-concept of using a CalDAV client such as Evolution to maintain event data on a website. I pretty much immediately had some ideas where I can use this stuff in some of my other code. At this point it's main deficiencies are:

• No user authentication
• No server-side understanding of the data
• No free-busy presentation of data

The first one is pretty easy, since everything I've seen so far expects to use Basic Auth for authentication, and (presumably) SSL for security.

The second one is a work in progress. I have started designing an appropriate object for handling calendar event data (I'm using PHP, and I don't believe that there is one already - mcal doesn't appear to do what I want).

The third one should be relatively straightforward, once I get my iCal event object a little further along. I could also use the free/busy publishing features of Evolution and not parse the data server-side at all. That might be a little easier to implement but it will be useful to parse that information for some of my other projects...

All in all it's looking fairly hopeful and I'm thinking that I might have a vaguely useful calendar store ready for light office duty in a week or two.