I've now released DAViCal 0.9.9, after five pretty intensive weeks of work. This includes a number of features that were implemented to support dotCal, which has now replaced their old Cosmo backend with DAViCal to break through a performance bottleneck. That turned into a six-week challenge, because Cosmo had wandered some distance from where calendaring standards are currently going, and so there was a lot of work under the covers of dotCal to switch from using various Cosmo-specific features to do the same thing, using open calendaring standards like CalDAV.

For several years now we've been buying our groceries online. It's worked well, and for the last couple of christmases I remember Heather adding a six-pack into the pre-christmas order so she could pull it out and hand it off to the delivery guy.

Fair enough too, because he was their front-line man. He was the guy who had to actually meet the customer, and even if only for two minutes face time, the impression he gave with his cheery "seeya mate" on the way out, and his always-happy smile, was that getting the groceries delivered was fun.

After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.

A friend e-mailed me this morning asking for some help with a problem he had where he wanted to make a folder writable by a group of people without making the files deletable. Stepping back from his question, I first pointed out that if the files are editable then they can be effectively deleted by removing the content from them, regardless of whether the directory entries themselves are retained.

One solution which occurred to me would be to automatically version the content of the directory, and this reminds me of why versioning of /etc has never worked for me: it only happens when I remember to commit.

I spent last week at the CalConnect XVI meeting of the Calendaring and Scheduling Consortium hosted by Apple Computer in Cupertino. I'd been hoping to get 0.9.7.3 released before I got there so I could concentrate on some of the more aggressive enhancement plans while I was there, but in the end I didn't manage to release until the Tuesday, during the event. Then, after some interaction with Kerio and a small but important bug that was found, I decided to release 0.9.7.4 with a very few small changes before moving onto the more radical enhancement plans I continue to work through at present towards a 0.9.8 release in a few weeks.

The release notes for both releases are on the wiki, including details of downloading and so forth:

• http://wiki.davical.org/w/Release_Notes/0.9.7.3
• http://wiki.davical.org/w/Release_Notes/0.9.7.4

At CalConnect itself, the first half of the week was an interoperability meeting which I was an observer at, though I did set up a server for people to test against, and the folk from Apple, Sun and Kerio were kind enough to test against this, including a very early version of the Symbian CalDAV client which is likely to be released sometime next year.

The second half of the week was a much more participative process, and gave me a much greater understanding of the general flow of the standards which are forming in the future. In particular it was interesting to get an idea of how close (or far away) the various nascent standards under development are. Some of the closest ones seem to be the Scheduling Extensions which is at draft 8, and will probably have only one or two more clarifying drafts before becoming an RFC. Next closest is probably the proposed CardDAV standard, and implementation of both of these in DAViCal is a priority for me.

The first thing I discovered too, was RFC5689, which is now implemented in HEAD and will be in 0.9.8. Another worthwhile standard, and relatively simple, is the Draft WebDAV Sync which is used by iCal4 if available, and which I have also implemented since leaving Cupertino. I expect there will still be some changes to the webdav sync specification, but it's relatively encapsulated so the effect of any changes are not going to be sweeping.

Support for the Scheduling Extensions for CalDAV, which I am working on now, will be more complete in 0.9.8, though probably still with a few missing parts. It is a large specification though it looks to be pretty stable now and is definitely time to move forward with it.

What the trip to Cupertino definitely showed me is that there is still a place for DAViCal in the available set of CalDAV servers. While there are starting to be quite a few around, and many are maturing nicely, there is still a niche for a free, standalone, SQL-based implementation like DAViCal and it is only through having a vibrant community of implementors around calendaring that we can flesh out the usable and useful standards that are continuing to come out of CalConnect.

Ultimately what impressed me the most were the people around CalConnect, who stand out as being a bunch of dedicated and thoughtful folk who really understand the importance of interoperation and open standards in this area. I do hope I have the good fortune to make it to another event at some point in the future.

I publish my photos on the internet. Well, I do when I get around to updating it, anyway. When I do so, I include some information about licensing them. I say to people "I'm very open to people wanting to use these pictures for something else, and will be happy to release photos into the public domain on request." so when I discover one of my photos abused by a travel website I do wonder why I didn't hear about it.

A few years back I remember reading this article by David Brin suggesting that it is hard for children to learn programming nowadays, and how it ain't happening so much any more. It's something that I have been wondering about for some time now, and it's something that I think has to be important for the future.

Is there really a huge slowdown in the numbers of computing graduates coming out of University? Perhaps there is really nothing there to worry about. Maybe there are so many more computers around, that even with a smaller percentage of users becoming programmers there will continue to be enough programmers around.

I found another interesting avenue for affecting a web application recently when Heather was trying to renew one of her magazine subscriptions. She mentioned that the site was getting a '500 Server Error' and I recognised the e-mail address it was suggesting, so I banged an e-mail off to advise the problem.

Curiously, they weren't able to duplicate the issue while I was still seeing the problem. I did a little fooling around and discovered that I only saw the error when I was making the request through my proxy server.

A little more digging and I ascertained that if I connected to the proxy normally via IPv6 I got the '500 Server Error', but if I instead connected to the proxy via IPv4 it all worked just fine.

I released a new 0.9.7.2 version of DAViCal yesterday. This reflects quite a lot of stability and small fixes for some subtle problems, and quite a lot of work with the iPhone, adding the possibility of a simpler configuration experience for iPhone users.

For several years I've wanted to join the Calendaring and Scheduling Consortium and go to one of their events to get a chance to meet face-to-face with some of the luminaries in the calendaring world, but every time there is an event it seems to conflict with either linux.conf.au or my brother's wedding or something. Finally I've decided I can make the next meeting, so I've paid over the money to join the organisation and I'm travelling to the US next month for 'CalConnect XVI'. With that on my mind when I saw an HP 110 mini netbook on sale for NZD$588 from Harvey Normans I finally flipped over the 'shall I get one' threshold, hoping it will make a good 'travel laptop' for the upcoming trip.

Something that has been annoying me recently with my bank has been that their website tells me that they will never ask for my password over the phone. And then their call centre asks me for my password. Over the phone. Of course the call centre doesn't mean my website password - they mean the special 'ultra-secure 5ekr1t code phrase', but they don't have a good, universally understood word to use for that. Hopefully they'll work one out, but they appear to have got the message anyway.

This got me to thinking about how these phrases are used, and how insecure they are in reality. After all when I store a website password I go to significant lengths to ensure that the same password is not represented by the same string of characters in my database. How vulnerable are our secrets in the databases of organisations we do business with?

Yesterday I switched my development environment to PostgreSQL 8.4, and so today I foolishly used the PostgreSQL 8.4 manual while I was developing, without thinking that I might be using some new functionality. Silly me!

What I wanted to do was to convert a column of words into a comma-delimited list (for readability, not for export), to get output something like this:

 id  |                   tags
-----+----------------------------------------------
 141 | DAViCal, FOSS, Programming, CalDAV, Releases
 138 | Family, Life, Kids
 137 | Kids, Family, Rants
 136 | Life, FOSS, Debian, lca
 135 | Releases, FOSS, Packages, Debian, DAViCal

Where the table has two columns 'id' and 'tag', like:

 id  |     tag     
-----+-------------
 141 | Releases
 141 | Programming
 141 | CalDAV
 141 | FOSS
 141 | DAViCal
 138 | Kids
 138 | Life
 138 | Family
 137 | Kids
 137 | Family
 137 | Rants
 136 | Debian
 136 | lca
 136 | Life
 136 | FOSS
 135 | Packages
 135 | Releases
 135 | DAViCal
 135 | Debian
 135 | FOSS

I looked at this and thought: that's just the job for an aggregate function! It's like sum(), except it concatenates!

Several weeks ago I was browsing around CalConnect wondering, as you do, if the timing will ever be right and the backing available for me to visit one of their meetings. It seems that the planets may actually finally be in alignment and I am really hoping that I can get to CalConnect XVI from 5th to 9th of October - though I will have to save my pennies.

In passing I noticed that the FREEBUSY Technical Committee has just published a Proposal for Freebusy Read URL, defining a bunch of optional parameters that can be used in queries against a freebusy URL. As calendar servers increase in power and scope it seems natural that these things will become more useful even if you might have thought time had passed them by, replacing them with more advanced CalDAV scheduling extensions.

Since DAViCal has always had Freebusy URLs, and in fact accepted a couple of simple parameters in them already it turned out to be a simple matter to provide these standardised ones as well. This change was included in DAViCal 0.9.7 which I released quietly into the wild a few days ago.

It's great that in these supposedly straightened times InternetNZ have wasted no time in confirming themselves as key sponsors for LCA in Wellington in 2010.

Now if only all of our other sponsors could line up behind them (please) and tell me the extent of their sponsorship, we would have some facts to moderate our plans...

But seriously: thanks to InternetNZ for stumping up with the basics to make sure this conference will become a reality.

Anyone else looking to sponsor the best linux conference in the world should send me an e-mail.

Soon...

:-)

After far too long (too many holidays away from my keyboard :-) I've released DAViCal 0.9.6.3 and AWL 0.36. This is mostly a stability release, fixing all those little niggles that might only affect a few corner cases, but it frees me up now to concentrate on adding more functionality for a 0.9.7 release in due course. Hopefully this will be the last in the 0.9.6.x series.

More information in the DAViCal release notes on the wiki.

There are quite a few changes to the AWL libraries which this release depends on, but most of those changes have been driven by my Work Request Management System and Capital APMS projects, rather than from DAViCal.