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.

I was going to reply to this in the mailing list, but after I spent half an hour furiously typing this, I thought it might be better to put it into a blog, for a slightly wider audience, perhaps a more permanent life and partly in an effort to end this thread on a more or less constructive note.

The backchat for this is that the LCA 2009 video has started to go up on the web, and some talks have some gaps in the audio stream... Russell Coker wants to make a constructive suggestion, as follows:

On Wed, 2009-02-25 at 18:02 +1100, Russell Coker wrote:
>
> I've pasted in the below paragraph (the third time I've included it in this
> thread) to reiterate my point. Note that I am not asking you to re-do any
> videos, I am making a suggestion for future people.
>
> # I suggest that in future when preparing such videos the sections with no
> # sound be omitted and replaced by a short note explaining the omission,
> # something like "sorry, due to technical difficulties four minutes of sound
> # were not available". Having a second ogg file for the lip-readers would be
> # an option although I expect that the demand would be minute.
>

As someone who has not been at all involved with the production of the LCA videos, but who has been intimately involved with the process of streaming DebConf 6, 7 & 8, I think this sort of additional effort will only happen if people voluntarily do it themselves.

Just the task of *watching* all of the produced videos is a huge job for one individual, but as a community of individuals it is quite likely that at least one individual in the community watches each video. If each person who was offended by the quality of post-production work took it upon themselves to fix up only one video then it is probable that we would see some changed. Otherwise I'm afraid it is unlikely.

Further in his e-mail, Russell Coker wrote:
>
> My observation was that the microphones were put down AFTER they ceased
> operating. A non-functional lapel microphone is no better than a non-
> functional hand-held microphone.
>
> Having a large supply of new batteries would be one way of alleviating the
> problem (I believe that some of the instances were due to flat batteries).
> Another possibility is having two microphones on hand so that if one died the
> other could be turned on.
>
> A wired microphone that doesn't rely on battery power would probably be the
> most reliable option. That of course might not fit with OH&S issues.

Most speakers are uncomfortable / unfamiliar with wired microphones. Spares are essential, of course, but the problem can usually be avoided by having a checklist for the audio person to confirm several things:

Before the start of the talk:

• check that batteries are good enough to last for the full length of the coming talk.
• check sound levels are correct for this speaker
• confirm sound is going through to recording
• check the speaker knows how to turn the mic off/on

At the start of the talk:

• confirm sound is going through to recording

At the end of the talk:

• Turn the mic off to save battery.

There are probably a couple of things that I've missed, but if you start with a checklist you pretty soon modify it into a *good* checklist, and it *really* helps when people are under fire.

In fact lapel mics are not the best microphones for these kinds of presentations. The best mics are the ultra lightweight 'headset' models which place a the mic near to the speakers mouth. These do not suffer when the speaker turns their head hard to the left or right, at which points a lapel mic stops getting their speech. They also work well with that more hirsute minority so over-represented in our particular community (alas, that this set no longer includes Bdale :-)

Of course DebConf has a large team of volunteers for streaming the conference, and has developed these kinds of procedures over a number of years. At DebConf there are usually only two main streams, each of which involves:

• The director, operating the video mixer
• Speaker camera operator
• Audience camera operator
• Slides to video convertor
• Sound mixer operator
• Talk timer, to warn speakers at t-10, t-5 & time is up.
• Two roving people responsible for getting audience mics to people talking in the room.

Ideally that really is 7 people (times two streams), and you can get by if you can't find all of the last three, but the other four are increasingly desirable. We mostly manage to do that with volunteers for two streams at DebConf, but for five or more streams at LCA it is inevitably a lot harder, and the quality necessarily has to be cut back to match the resources available.

While it is true that sound is critical to this communication, it is unfortunately also true that most people's (even most geek's) eyes glaze over when presented with a mysterious box with a mere 6 sliding potentiometers, let alone when there are 36 of them, each associated with another 8 rotary knobs, and a rats nest of cables worthy of the worst network nightmare they've seen, and where everything appears to be literally held in place with duct tape.

So it is not so surprising then that while it is relatively easy to find a gadget mad geek capable of operating a camera, or even experienced with operating a camera, finding people with experience operating a sound mixer is an order of magnitude harder.

At LCA the operation appears superficially to often involve a (single) speaker camera operator with a very basic sound mixer which has been configured once by an overworked person who is unobtainable during the actual talk to solve any audio problems. These people are volunteers, and are doing their best, but it simply isn't possible to get a consistently high quality of video and audio in those circumstances.

So as one of the organising committee for LCA 2010 in Wellington I will be watching what we do, and although I don't intend to get personally involved in the video production (I've got plenty of other stuff on *my* plate :-) I do intend to provide what advice and assistance I can. I know that we hope to have some professionals involved (as volunteers), but how many volunteers, and with what levels of skill & experience, we are unlikely to know until much closer than the date. I'll also personally try and get a run-down on all of the audio equipment so that in an emergency, if I happen to be available, I can sub as a sound mixer operator.

So we will try and do better in Wellington in 2010. Come to the conference, though, because we can make no guarantees, and if you do come to Wellington, and you see a single cameraman, and you know something about running a sound mixer, then perhaps you can come and volunteer to help out in that capacity, for the talks you are attending anyway. We'd really appreciate the help.

And finally I must say thanks, in particular, to Holger Levsen for all the learning I have gained since joining the videoteam at DebConf5 in Helsinki in 2005. And too, to all of those past conference teams (LCA, DebConf and otherwise) who have put their best efforts into providing videos of the talks I couldn't see in person. I know it's a bloody hard job, and often a less high profile one, so:

Thank You.

The news is out now, that Wellington will be hosting LCA 2010. As someone on the core team for that (potential sponsors please contact me sooner rather than later :-) I really hope we can do something as awesome as the current week we've had here in Hobart.

Thanks to all of the Hobart team for doing a great job.