DAViCal 0.9.6 pre-release packages
Here are some pre-release DAViCal 0.9.5.90 (i.e. nearly 0.9.6) packages now. Since there is a lot of refactoring that has gone on under the covers here, I'll publish these packages so that people can tell me about all my embarassing mistakes, and I can correct them, before I upload them to places where they might get installed more or less automatically.
In particular if you do find problems with these, and can catch me on the #davical on irc.oftc.net during the coming week I should be able to include a fix into the real 0.9.6 release next week. If you can't get on IRC then an e-mail will also be fine.
The full release notes are here but the short version is that this fixes a number of bugs, notably one to do with importing calendars containing repeating events with exceptions. The big change is that this adds the initial support for the draft scheduling extensions to CalDAV, in particular the lookup of free/busy information.
Updated
In true pre-release fashion I forgot to actually enable the scheduling extensions stuff, so I've put new packages (0.9.5.91) on there now with that enabled... :-)
I still remember seeing
I still remember seeing davical in the Debian new packages list, eagerly investigating because I've wanted a CalDAV server for a while, seeing PHP in the dependencies, and deciding to look elsewhere.
Why PHP?
Yes, I wrote it in PHP. I did that naturally enough because I am very familiar with PHP, having written quite a lot of code with it over the last ten years.
You're presumably trolling about this because PHP has a fairly sucky reputation for security, which is mostly as a result of a lot of bozos having written crap code with it, and with a kernel of truth because a few bozos have written crap code inside it. .
For the most part, however, I find PHP to be particularly easy to set up for virtual hosting and quick in the ways that are important to me:
While I write a reasonable amount of code in Perl, I'm just not efficient at it. I'm getting better, and in a year or two may attempt a web application in it (at the moment I've using it to develop a GUI front-end for dvd-slideshow). I've tried Ruby a bit in the last couple of years too, and it's a beautiful language. It also shouldn't be tarred with the same brush as RoR (as it often is) which has plenty of bad points in with the good.
Other languages that I've used historically include offbeat things like Progress 4GL, COBOL, Pick Basic, C, Rexx, Assembler, and so forth. All of which have plenty of opportunities for blasting big holes in both your feet, but which for one reason or another aren't the thing for developing a modern web application (well, except maybe C :-)
As with most applications involving storage of data, the heavy lifting here is being done by the database. In reality PHP is mostly being used for parsing & validating the input and turning it into a query, and then processing the query results into something suitable to hand back to the client.
Ultimately, though, if you don't want applications written in PHP you should choose a different server. There's plenty of choice for Java or Python fans. Well, perhaps 'plenty' is not the right word, but more choice than there is for PHP fans!
"PHP has a fairly sucky
"PHP has a fairly sucky reputation for security, which is mostly as a result of a lot of bozos having written crap code with it, and with a kernel of truth because a few bozos have written crap code inside it."
I honestly don't blame the security of PHP apps on the authors of those apps; I place it entirely on PHP itself. My apologies that it came across otherwise.
As you said, PHP often proves quick to install, quick to code in, and quick to run. It offers various benefits that encourage people to code in it. It then proceeds to make the obvious and default things the wrong and insecure things, and make the correct and secure things non-default and entirely non-obvious. You *can* write secure code in PHP, but it requires much more work than writing insecure code. As such, I automatically assume that any PHP code has security holes, and I refuse to install PHP on any system under my control.
To use Rusty Russell's terminology, PHP may have succeeded at making the language easy to use, but they failed to make the language hard to misuse. See http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html and http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html for more detail. And I don't ascribe this exclusively to PHP (gets() anyone?); PHP just has these problems to an extent I've seen in few other projects.
Maybe Davical doesn't have any security holes. Maybe you went out of your way to write secure PHP code, and successfully avoided all of the various traps PHP entices you with. I have no doubt that you and many other PHP programmers have the skill to do so.
PHP Security
I have had DAViCal reviewed for security flaws by a well-respected local professional, although that was more than a year ago. At the time he pointed out several very minor issues, which I believe have been resolved, and indicated that he believed that it was in general very secure by nature of it's design.
I don't know if this is still the case, and I've been thinking of asking for another review at some point. In general I do endeavour to write the code in ways that should structurally avoid security problems, although of course people should consider carefully who gets write access to calendars.
I also think that PHP is becoming more secure over time, and that's a good thing of course. And yes, I believe that I do follow or exceed current PHP best practices for secure coding, although I would certainly welcome review. For all of open source's trumpeting of the 'many eyes', there really aren't that many eyes out on the edges of the open-source universe. I know that I personally only read a very small percentage of the code that I run.
Cheers,
Andrew.
PS. I particularly like Rusty's point #3 in that second link, and am reminded of a co-worker learning Unix through a tutorial back around 1991. He was following the examples, entering in the commands and watching what they did, and then reading about them in order to understand them better. God knows why, but he was doing this as 'root', and of course the command that woke up everyone on the floor was when he typed in "rm -rf /" before reading the text following it which started "Don't...". In a cascade around the office people everywhere were all going WTF?! and looking up from their cubicles in confusion.
I must say I'm looking at
I must say I'm looking at DAViCal for about year with hope it will get usable for me. I didn't still find anything that would be closer to what I expect from opensource caldav implementation than DAViCal. But some thing are still hold me back from using it. And they are:
- support of other DB backend (some DB abstraction would probably do it)
- syncml support (universal way how to sync nearly anything)
And I hope DAViCal some day gets these things and I can start using it.
Those missing bits...
Those are both high on the list of things that people ask for, and they are on the roadmap, but they won't arrive in the short term.
The database independence layer will come at release 1.1, which I will do as a new branch after 1.0 is released. The 1.0 roadmap is intended to come when I have good coverage of the draft scheduling extensions for CalDAV. Hopefully the fairly radical changes in draft-05 of these specifications last month is the last such revision, and they get set in stone in something fairly close to their current form.
Once that's incorporated into DAViCal I can release 1.0, and then switch primary development efforts to a 1.1 branch which will switch to PDO for database access. At the same time I will be refactoring other areas to use some PHP5 features which I have avoided to date in the interests of backward compatibility with PHP4. It is at this point that I expect to provide the opportunity for translation of SQL into other dialects like SQLite.
As far as SyncML goes it's something that I would love to see supported. There is a patch for it against the feature request on Sourceforge which included large chunks from the Horde Project, so I obviously couldn't apply it directly, but if someone were to take that, de-bitrot it and feed it to me in more digestible chunks using references to external projects if necessary, rather than just including them wholesale, then it will eventually arrive. I don't know if it's possible to support some small subset of SyncML as a starting point, but if it can be done in bite-sized chunks then that's good too.
I believe that SyncML support could also possibly be attacked by a separate system potentially using the caldav-client library included in DAViCal, and making CalDAV requests to a DAViCal (or other CalDAV server) backend while talking SyncML to the clients.
How long that all takes depends, I guess. Implementation of support for other databases will naturally depend on someone volunteering to do that for the databases they are familiar with.
The SyncML support will happen if (a) I manage to get my Nokia 6275i working with Linux, or (b) I get an OpenMoko or something which can already talk to Linux or (c) someone else does it.
There's a 'mob' branch in the DAViCal repository on repo.or.cz which is available for anyone to commit to, and which is potentially a good way to submit patches.
Regards,
Andrew.
I totally understand reasons
I totally understand reasons you write about and I hope someone who can help with programming (not like me :) appears.
For your mobile maybe have a look here -> http://www.opensync.org/wiki/DeviceCompatibilityList . Altough your model is not on the list I don't think it is very different from other S40 (I guess) Nokias.