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.

I like my music, although I find that I can't stand sticking headphones over (or in) my ears in the normal course of events. When I buy a CD I carefully rip the music off it so I can then put the CD in a cupboard. This has saved quite a number of them from the never-to-be-underestimated destructive power of an absent-minded child.

Over the years I have had a kind of low-key desire to find some decent software to allow me to find, categorise, playlist and free-associate all this music. It's been a "low-key" desire because I wrote my own software to do this some time ago, but it's kind of crude (browse artists / albums, find artists / albums containing tracks matching a regex, enqueue / pause / stop). This is mostly OK for me because I wrote the software and know how to work it, and it provides some ability to stumble over tracks that had been forgotten, but I think the UI really must suck quite a lot since Heather generally prefers to use the CD player directly.

What makes my requirements so hard to meet is that the PC I play my music from is in a cupboard and it doesn't have a keyboard, mouse or screen. I guess most people wanting to set up a "multimedia PC" actually want more than one media on it. We don't have a television in our house, so the cupboard is just fine. Everything is on the LAN, so we can use the keyboard / mouse / screen of our local PCs.

That's all well and good, but playing music is kind of fickle. I don't want us fighting over what stream is playing at the moment, or (possibly even worse) just mixing them all together. Also, the music is on the computer, and the soundcard is on that computer - so there shouldn't be a need for the files to be transferred across the network twice to play them. Sometimes I like the music to still be playing when I'm rebooting my laptop too.

So on Friday night, Brenda pointed me at Amarok, suggesting that it does evrything that anyone could possibly want in their music player, pointing out that it even had these plugin scripts that it could run, which would allow for a web interface and everything...

On Saturday I installed it, and I must say that it is the most sophisticated music player I have come across, and it really did help me find and categorise my music through a very well thought out interface. Unfortunately that well thought out interface only applies to the GUI, meaning that I still need to be SSH'd into my music server to control it fully. The web interface scripts are unfortunately fairly simple and still require substantial mucking around.

I love New Zealand music in particular, and one of the things I thought Amarok did particularly well was handling podcasts. The ease with which I was able to add an RSS feed and play episodes from it immediately encouraged me to catch up on Liz Barry's NZ Music show which has always wanted to play on my laptop when I use my normal RSS reader. Now that I've done this through Amarok I can see that whatever I switch to will need to support this sort of thing in a straightforward manner.

It all looks pretty hopeful though so I might look to taking some client/server model music player, tying it into the Amarok database, and making a front-end work with that. I'll probably pick over my existing code and see if something could be done with that, or take a look at Music Player Daemon (mpd) which seems to start with many of the ideas about remote control that are right for me, albeit without the database support that I like in my own setup, and which Amarok seems to do very well.

I've done all my interface coding for my existing setup as a web front-end. The Music Player Daemon doesn't rely on a web interface though - it is a more traditional client-server model, and this is undoubtedly a good way to be for something where the action happens at both ends in an asynchronous manner. There certainly seem to be a good set of clients for mpd.

In any case the time has definitely come to reexamine my options for playing music. It's probably five years since I set this up and wrote my crude player and the world has moved on.

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...

From our work today the Nokia 770 is definitely looking like it will do what we need. There are still lots of challenges, and it will be a real miracle if everyone manages to get their act together to get our client's application up and operating on these by early November.

Meanwhile I'm even more impressed with it today than I was yesterday, I think. Right now it just told me (for the first time) that the battery is low. This is after Heather had another go at it so the thing has been used continuously for the last seven hours, including Heather about two hours listening to downloaded audio while browsing.

Right now I'm SSH'd into it while it's playing a stream (with mplayer) and I have now found a bunch of repositories that have the 'armel' packages (including the one with DropBear for armel along with a bunch of other useful stuff. The Maemo.org site seems to be really useful, although some pages in the Wiki perhaps need reviewing - it seems that quite a number of the enhancement possibilities have been followed through on.

Finally, a couple of minutes ago, the device informed me it has a low battery, and shortly over that it dropped the wifi connection and my stream connection (and SSH connection) died as a result. I guess that 7.5 hours is a pretty good deal, especially for such intensive use.

That intensive use included things like re-flashing the device when I tried to upgrade to the Sardine distribution (without an SSH connection into it) and some package was killing the X server during upgrade, and eventually killing it on boot.

So if it's gone to sleep, I guess I should to!

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.

My previous efforts to purchase a Nokia N770 finally came to fruition this morning when two of them were waiting on my desk when I arrived at work. I was very happy, although if these do the job we'll have to go through that all over again to buy the next 20 or so...

For the curious, these were ordered through the Nokia UK website, delivered to the relative of a workmate passing through England for a conference who then collected them and posted them to us. We might have to find a simpler way for the next lot...

First Impressions

Can it really do what I want it to do? Is it usable? Although I've played with these before (in Helsinki before they were released, and in Mexico earlier this year) I have not had one in my hands long enough to really get to grips with the user interface.

Now I have one that I can play on without restriction, I can see that it is all really well-designed for the form factor. Nokia do seem to do this sort of thing very well, and the software all integrates very nicely, and be very stable. So far I've only managed to crash one application (the browser) when trying to resize the screen while viewing the UI from Hell. Hardly unexpected - that particular bit of Flash (Crash ?Trash?) seems to break most browsers in this household.

To try and gauge the battery life I handed it over to Heather for the evening. She found it fascinating and didn't put it down for about five hours - with the battery icon still indicating a full charge. The battery icon did suprise me, in that you can't click on it, or mouse over it to get more information. In fact the oddest thing I have found so far is that there was no 'Power' item in the control panel and the only control over power seems to be under "Display" where you can set screen dim / blank timeouts. No separate adjustment for when you have it plugged in, or for how long before the WLAN chip times out, but perhaps the battery life is such that I won't find myself doing it regularly and my desire to fiddle with such settings is foolish.

Hacking In ...

Well, I didn't manage to stave off my desire to fiddle for very long at all... maybe an hour after I got the device I had downloaded a backup image, in case I have to reflash it back to a known state! First up was the need to install an XTerm, which proved relatively straightforward after adding an APT source pointing at http://maemo-hackers.org/apt/ (although you do this through an Application Manager of course :-).

Once I had the XTerm installed I can get into the Linux installation, but to get root I need to do something more complicated. The Wiki suggestion was that I install an SSH server and ssh in as root so I downloaded the Dropbear from my laptop and saved it directly onto reduced size MMC in the N770, mounted as USB storage on my laptop - very easy. The installation of a downloaded version of Dropbear failed though, and unfortunately the "Application Manager" didn't display the error messages. So I proceeded to use the "flasher" tool to "enable R&D mode" which eventually succeeded after many unsuccessful attempts. I seemed to need to:

• power the N770 off
• hold down the "Home" button
• press the power button
• insert the USB cable as soon as the screen lit up

It seemed that it wasn't possible to power on the device while the USB cable was inserted.

Reading the documentation further, it seems that it should be trivial to create a Debian package which could be installed to replace (or edit) the "gainroot" script so that it doesn't check for R&D mode, and I think I will do that if we are going to be getting a bunch more of these.

Anyway, now I had root access I could see that the Dropbear packages wouldn't install because they were the wrong architecture. It seems that I must have a slightly newer model than the documentation (and many of the packages, I guess) apply to, and that the architecture is 'armel' rather than 'arm'.

I suppose this means that next up I will need to download scratchbox and set up a build environment so I can build that SSH server, and probably so we can build all sorts of other things to go on there.

I'm looking forward to it, although it has somewhat distracted me from my CalDAV investigations, which were really starting to get somewhere useful.

In my continuing search for a CalDAV server I have to confess I have avoided the Java solutions. I have a number of problems with Java, not least the fact that it is not DFSG free, although that seems to slowly be changing.

My initial goal is to find a server which I can use from an Evolution CalDAV client for a few fairly simple reasons:

• I use evolution for calendaring and e-mail
• Evolution is nowadays a quite stable and mature e-mail and calendar client
• I want to understand the CalDAV protocol and the documentation is all but impenetrable

Anyway, after playing with Apple's newly public Calendar Server, looking briefly at Chandler in the process, trying to find the Hula CalDAV support I moved on to look at Cosmo.

Java on Debian - the modern way

Cosmo is a java application, and it appears to require JRE 1.5 or later. Forunately things with Java aren't nearly as complicated nowadays as they used to be on Debian. I went to Sun's java download and got the latest J2SE 1.5 JRE and turned it into a Debian package using "make-jpkg" from the "java-package" package, installed that and used "update-alternatives" to make that my default Java:

sudo apt-get install java-package
make-jpkg jre-1_5_0_08-linux-i586.bin
sudo dpkg -i sun-j2re1.5_1.5.0+update08_i386.deb
sudo update-alternatives --config java


Starting Cosmo Running

I downloaded the current Cosmo 0.4 + Scooby 0.2 package, unpacked it and ran the start script:

JAVAHOME=/usr bin/osafsrvctl start


Following the Cosmo setup instructions I then browsed to http://localhost:8080/ and created myself an account.

Since I've also been reading far too much about CalDAV and getting things working with Evolution, I also went into Scooby and added a calendar appointment to ensure a calendar was created for that user.

Configuring the CalDAV Calendar in Evolution

In Evolution I then added a CalDAV calendar with a URL of "caldav://localhost:8080/cosmo/home/andrew/" and added an event. Although I could see the event uploaded, this proved to be the wrong answer, and I needed to point Evolution at the "Scooby" directory:

caldav://localhost:8080/cosmo/home/andrew/Scooby/


Now that I have done that I can happily create events, stop evolution, clear out the calendar cache files, restart evolution and have the event show up. Phew.

Differences between Cosmo and Apple Calendar Server

Clearly Evolution CalDAV is sensitive to some differences between Cosmo and Calendar Server. Sniffing the traffic when I start evolution with an empty cache in both situations there are a couple of differences:

• Cosmo's response to the REPORT query is prettily formatted
• Cosmo's response uses entity names like <D:response> whereas Calendar Server simply returns <response>

My bet would be that it is the last one that is a problem, and that Evolution CalDAV requires the more complex "<D:multistatus xmlns:D="DAV:"><D:response><D:href>" form rather than the simpler "<multistatus xmlns='DAV:'><response><href>".

All I am left is to wonder which style is correct, and whether this is a bug in Calendar Server or in Evolution-CalDAV.

Following on from my fun with Evolution and Apple Calendar I thought it was time to get Evolution running against a CalDAV server so I can see what the protocol differences are between a working and non-working installation. Surely, if Evolution is claiming CalDAV support there must be something out there which it has actually been used against... mustn't there?

At first, looking at the packages from European Bob it seems that these aren't all that up to date either. The current SVN revision I have checked out is 2401, his packages are revision 862 and the Debian packages are revision 379, so I guess I will try and build it...

First, make sure you have the necessary development packages installed:

apt-get install bison apache2 build-essential slapd ssh subversion libtool automake1.9 libssl-dev python2.4-dev libpopt-dev flex pkg-config libldap2-dev


Next, fetch the code from the Hula repository:

svn checkout https://forgesvn1.novell.com/svn/hula/branches/hula-store/hula


But then I read European Bob's blog (linked from his Hula page) I see he actually does have version 2401 packages there for Ubuntu Dapper, so I try those instead of building the whole shebang...

... but then, after installing them and configuring them and trying to find some documentation that might indicate how this CalDAV success was achieved, I find this message saying CalDAV will be implemented against the store Real Soon Now.

I also had some confirmation of that on IRC:

13:46 --> You are now talking on #hula
13:48 <karora> Hi, I'm trying to configure Evolution to use Hula as a CalDAV
backend, but I can't seem to find any documentation for doing
that...
14:55 <boc> there is currently no working support for caldav in hula
14:56 <karora> OK. Thanks - I was misled by a blog post from August 2005, it
seems.


Bummer, stymied once again.

Next up: perhaps I can have a go at Cosmo, although I think I am starting to go in circles again.

It seems I was fooled into thinking that Evolution/CalDAV was working against Apple's Calendar Server because of some bad configuration I had in Evolution.

A little more investigation shows that everything appears to work fine until I try and add an event to a CalDAV calendar, at which point Evolution crashes pretty hard.

Debian evolution is currently at version 2.6.3 but it's hard to see from Gnome CVS if there have been many patches to this since it went in.

Sniffing the traffic to the Calendar Server suggests that the Calendar Server is doing the right thing. There is an OPTIONS request from Evolution, and an appropriate response from Calendar Server. Then there is a REPORT request from Evolution and what appears to me to be an appropriate response from Calendar Server that lists the relative URL for the event I have created, but evolution crashes at that point and doesn't seem to request the .ics file for the event. It may be that Evolution wants the event to be reported in-line, rather than as a URL to be further retrieved, although both approaches seem reasonable within the CalDAV spec.

Supposedly Evolution is built to operate agains the Hula CalDAV backend, but last time I checked that out there was no sign of the hoped-for CalDAV support. Probably I was optimistic to use the Debian packages, but it's hard to see release numbers of anything from the Hula website. I think I might have a go at fetching the latest from Subversion or using the Hula packages from moo tang clan.

Meanwhile, my CalDAV in evolution is again turned off.

Following on from some failed attempts on Friday, it seems that Andrew Ruthven has had some success getting Apple's Calendaring Server going on Debian. Great! I managed to duplicate Andrew Ruthven's success after five minutes by applying his PyKerberos patch so I now needed a calendar application that talks to this...

One of the reasons I had been trying to get this going in the first place is that Evolution has a CalDAV plugin. Andrew had told me that this didn't work for him though, and after quickly failing myself and not finding a lot of help from debugging information, or from sniffing with WireShark, I decided to try Chandler.

Trying to use Chandler

I tried to roughly follow the build instructions from the Chandler website to build Chandler on Debian unstable. The downloadable builds strongly suggest that they won't work except on Ubuntu Breezy, so I didn't initially go to them. Unfortunately (or perhaps fortunately) the builds.osafoundation.org server appeared uncontactable and this is where a vast raft of stuff seems to want to be downloaded from.

So I went for the .tar.gz binary download that the Chandler folks currently build on Breezy and in spite of all of their caveats it seems to work just fine on Debian Sid.

Well, maybe "just fine" is exaggerating, but this is 0.7 alpha 03 release, after all:

• Pressing 'Today' showed me the past week.
• Trying to edit the date/time of an appointment made it rapidly and wierdly move into the past
• It didn't appear likely that I would use this application even if it did work for me.
• It seemed to be about as usable and stable as Evolution was pre version 1.0

That made me really sad. I had got Chandler to connect to the CalendarServer, even if I couldn't see that it was writing any appointments to it. The URLs used and so forth were enough of a clue bat to point out that I needed to connect to

Getting Evolution Working

It turns out to be pretty simple to get Evolution to work with the existing 'admin' user:

Adding a new user

OK, so lets add ourselves as a user...

Edit the file conf/repository-dev.xml and look for an element called '<accounts>' near the bottom of the file. You need to paste your user in something like this:

    <user>
      <uid>andrewmcmillan</uid>
      <pswd>password</pswd>
      <name>Andrew McMillan</name>
      <calendar>calendar</calendar>
    </user>

Then configure your new calendar with the "URL" set to "caldav://localhost:8008/calendars/users/andrewmcmillan/calendar/" (because we told CalendarServer to put the calendar into the 'calendar' folder. The "Username" should be set to whatever you chose, of course.

Where to from here?

Well, I think that I probably need to read the docs for this now :-)

I want to try and create a bunch of users, resources and the possiblity of other's sharing calendars. Creating resources looks easy enough from the repository-static.xml example, and I seem to have done that, but I think I need to get together with some of the other guys at work fiddling with this and see if we can do a shared installation.

After that, of course, I will be looking for some Debian packages of it all. Especially since it was this Debian ITP message that got me (re-)started on all of this. Good luck Guido!