DAViCal 0.9.7 released
Published on Friday, the 26th of June, 2009
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.
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.
Another change in DAViCal 0.9.7 are the use of significantly enhanced algorithms for selecting events to appear in time-range queries. In the past these were selected in an inexact manner, erring in the direction of "well, the clients will only display the events you really want to see, so it's OK to give them a few extra ones". That works fine for the standard clients everyone uses: though it added a smidgin more bandwidth from time to time, it was a little less work for the server. For non-standard clients, however, it was much less desirable and some users desired a more exact set of results. So in 0.9.7 I finally switched over to the use of the in-database RRULE parsing functions that I have been working on for some time. These functions improve the exactness, and it turns out they also generally operate faster than the earlier logic as well.
The other important change for 0.9.7 is that it will work with the iPhone OS 3 Calendar App. In fact this would have been much harder for me without the support of the nice folk at Truhearing (suppliers of discounted hearing aids) who are so keen on DAViCal that they bought me an iPhone just so that I had no excuse! And indeed having the iPhone certainly does make a difference to the way I use DAViCal myself - not just for the fact that it has enabled me to work around a few iPhone issues, and to fix some DAViCal issues, and the two are now playing nicely together. I still see a few iPhone issues (appointment end times sometimes show up with +12 hours on the iPhone if created elsewhere... and I'm in UTC+12... coincidence? Also there is no way to move appointments between calendars, and no easy way to set the timezone just for one appointment) but no doubt the more critical of these will be resolved in future releases.
Interest in running the code to support the iPhone has meant that a wider cross-section of DAViCal users have been running the updates prior to release, as a result this is probably one of the best tested releases ever, and the community has been really helpful in making it so.
For now, the new version is hosted on my server. Tomorrow I'll upload it to Sourceforge and publicise the release more widely.
Flattr
![[D]](/images/tag_delicious.png "Submit to Del.icio.us"){kind=small}
![[Digg]](/images/tag_digg.png "Submit to Digg"){kind=small}
![[FB]](/images/tag_facebook.png "Set status on Facebook"){kind=small}
![[R]](/images/tag_reddit.png "Submit to Reddit"){kind=small}
![[SU]](/images/tag_stumbleupon.png "Submit to Stumble Upon"){kind=small}
![[Tweet]](/images/tag_twitter.png "Set status on Twitter"){kind=small}
Just installed 0.9.6 last night
Hi,
I appreciate all your hard work. I think it goes without say that I just installed 0.9.6 last night... hehe...
I need to use 0.9.7 if it fixes the iPhone problems, but my install procedure was a bit complex, no doubt because of my general lack of knowledge (here's what I did to install DAViCal on a Webmin/Virtualmin box running under CentOS: http://www.u.arizona.edu/~amlake/computing). I'm wondering what the least disruptive way to upgrade to 0.9.7 would be. For instance, if I use an rpm -ivh would that destroy anything in my existing setup? I believe most of the "setup" is actually in the postgre database, but there are a few config files, etc. Should I merely copy a set of .php files over the 0.9.6 version, use the rpm, or something else?
Thanks,
Tony
Davical 0.9.7 and iPhone
Hi Andrew,
Great work, Davical. I use it on my apple computers and am very happy with it.
It made me even more happy when I found out my iPhone is supporting caldav to!
And even more happy when you started to fix 0.9.6 when it did not work on the iPhone!
I am almost a happy man :)
Almost... because 0.9.7 did not fix anything on my synchronisation between iphone and server. The iphone does see al the calenders (multiple calenders with 1 user) but does not get the items in the calenders. Creating a new item on the iphone gets distributed to the server but not the other way arround :( Any idea's how to fix this?
Make me happy again ;)
Rob
Hi! I appreciate your work
Hi!
I appreciate your work too. Altough I've installed the debian packages of awl (0.37) and davical (0.9.7) - I still get no events on my iPhone - Thunderbird and iCal works perfect. Do you have any ideas? Could you please put up a howto for the iPhone Setup (Server and Client). Would appreciate that really really much.
greets, Phil.
How to get it working with the iPhone
I've published some iPhone setup instructions on http://www.davical.org/ now (well, some time ago, in fact).
Typically the problem is that the iPhone is configured to ask for more data than it can handle. Generally people seem to find that setting a 'Sync' (under 'Calendars' in the 'Mail, Contacts, Calendars' settings) of 'Events 2 weeks back' means the iPhone actually succeeds in syncing, otherwise it seems to exceed some internal memory limit.
Cheers,
Andrew.
Davical 0.9.7 and iPhone
Hi David,
You rock mate. Davical continues to be an important business tool for me. I still can't believe you do it for free.
Just wanted to let you know that I'm having the same issues as Rob (above) with my iPhone. If set-up as a "subscribed calender", the iPhone picks up my single calendar and displays all events.
If set up as a CalDav account, the iPhone will not show events. Even when set to sync 2 weeks of data.
Sorry I can't help you with coding mate. I'm not particularly talented with anything other than simplistic scripts. But if I can help in any other way, please let me know.
Anyway, thanks again.
Bryce
Solving problems with DAViCal and iPhone
Hi Bruce,
I'm glad you like DAViCal, but sad that the iPhone can't use it correctly for you. I'll try and see if I can duplicate your problem (it works like a charm for me here :-) but the most useful thing you can do is to capture the communication between the iPhone and DAViCal.
Usually this means disabling encryption for a period, and running a program like ngrep, tcpdump or wireshark on the server to capture the communication 'on the wire' so to speak.
The best place to get support is not my blog though - it's much better to go to the IRC channel (#davical on irc.oftc.net) or on the mailing list.
Regards,
Andrew McMillan.
Davical 0.97.2 and IPhone OS 3.1
Hi Andrew,
first of all I want to thank you for all the work you spend on this excellent project. I never saw a better calendar server for use with Thunderbird/Lightning! Even got it working on Win2003 with IIS, PHP and Postgresql! (I know, this is not the best combination, but I am stuck to Win because of other applications).
Unfortunately I cant (as the other commentators) get any events into Iphones Caldav calendar, reguardless of the settings for syncing. On the other hand a new event, which is generated on the IPhone, is transmitted to the Davical-server and can be seen in Lightning. But changes to that event are not seen on the IPhone, as it doesn't see any events.
Hopefully you will find a solution for this. Davical and Iphone and Lightning were a great team!!
Thank you again from Germany!
Yours
Peter
DAViCal 0.9.7.2 and iPhone OS 3.1
There are a few things you can try, in order to sync. One of the commonest issues with the iPhone seems to be that it stops working if there are too many events (or something :-) and if you set the sync period on it to 'the last two weeks' it might start to work.
After upgrading to 0.9.7.2 it is a good idea to disable / enable the account (open the calendar app in between disabling and re-enabling too).
Finally, make sure you have it installed in the root of the virtual host, rather than in a subdirectory, and enable URL rewriting too.
If you're still having problems, try and chat to us on IRC (#davical on irc.oftc.net) and we'll see if we can sort out what is going wrong.
Regards,
Andrew.
iPhone problem
Hi,
I've been experiencing the same problem as others that the iPhone is not syncing events from the server. Having some technical knowledge, I've sniffed the network traffic and I think I can see the problem:
The iPhone is requesting this:
<?xml version="1.0" encoding="utf-8"?> <x0:propfind xmlns:x1="urn:ietf:params:xml:ns:caldav" xmlns:x0="DAV:" xmlns:x2="http://apple.com/ns/ical/"> <x0:prop> <x0:displayname/> <x1:calendar-description/> <x1:supported-calendar-component-set/> <x2:calendar-color/> <x0:resourcetype/> </x0:prop> </x0:propfind>In response, davical is sending this (abbreviated for emphasis):
<response> <href>/cal/caldav.php/cpw%40weeksfamily.ca/</href> <propstat> <prop> <displayname>Christian Weeks</displayname> <resourcetype> <principal/> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <C:supported-calendar-component-set/> <C:calendar-description/> <A:calendar-color/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response>The other entries for other calendars all have the same problem. The secondary <propstat> with 404 Not Found status.
Note that it goes ahead and queries the server for the /home calendar, and get's back a list of resources:
<response> <href>/cal/caldav.php/cpw%40weeksfamily.ca/home/20090917T170011Z.ics</href> <propstat> <prop> <resourcetype/> <getetag>"ae2fb7a0586ea40985176a58a162e57a"</getetag> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response>I notice that the phone does not follow up by actually querying those ICS URLs however. My thoughts are:
The 404 not found error is confusing the phone about the presence of the calendar. So it fails to list the calendars on the phone (I get no list of available calendars, even when there are several). However, it thinks there are, and is trying to display them, but gets confused and fails to. It's probably a bug on the iPhone to get confused about the 404.
My speculation is that it will work as long as it can find a calendar with that property set, which probably comes from the Mac iCal client, hence if you create your calendar in iCal it works..
Hope this helps. Feel free to email if you want my tcmpdump dump files.
Christian
The CalDAV communication process for an iPhone
This is all a perfectly normal CalDAV request/response set. When you see:
<propstat> <prop> <C:supported-calendar-component-set/> <C:calendar-description/> <A:calendar-color/> </prop> <status>HTTP/1.1 404 Not Found </propstat>you are seeing that as part of an HTTP multi-status response (response code 207 for the whole request) and DAViCal is saying that for the 'href' in question those particular properties are not defined. So the collection does not have a colour or description set, for example. The odd one out in this particular case is the 'supported-calendar-component-set' which is not a client-supplied property, but which in DAViCal is only defined for calendar collections. This particular request was made against a DAViCal principal, which is not a calendar collection (though it is a collection).
This is all normal stuff, and the iPhone doesn't require the colour or the long description to be set even on calendar collections. These can be set from iCal, however, if you change the display colour or description there it should save that property to the server.
As for the later requests: it is common for clients to request the 'getetag' and compare the received value against some internal cache. If the value matches then they won't bother downloading the actual content, since they can be assured (by the definition of HTTP ETag) that the actual content is the same stuff they downloaded previously.
The iPhone OS 3.1 (and apparently the iPod OS 3.1.1) do work with DAViCal 0.9.7.2 onwards. There are a few regular problems that can occur. One is that if the calendar has many events the iPhone seems to just give up so you may need to set the sync period to only 'two weeks back'. Also, if you upgraded to OS 3.1 before upgrading to DAViCal 0.9.7.2 you will need to disable the CalDAV account, open the calendar application, and then re-enable the CalDAV account.
There's a bit more stuff on the wiki about using DAViCal with Apple devices too.
If you're still having problems, please join us on IRC (#davical on irc.oftc.net) or e-mail me.
Regards,
Andrew McMillan.
Caldav with iPhone
I have upgraded to Caldav 0.9.7.2 and awl-0.38
I got the same issue with iphone sync:
davical: LOG: calquery: Query: QF: Error in '/usr/share/rscds/inc/caldav-REPORT-calquery.php
It work with Thunderbird & Sunbird.
Then i upgraded the database...
dba/update-davical-database
and now it work perfectly.
Thanks for your work guy!
Caldav with iPhone
Hi,
I can manage to have to iPhone pass the calendar validation test, however I see no event in the iPhone although events display perfectly in Thunderbird.
I saw Arno's comment and tried to update the databse.
here's the output:
The database is version 8.3 currently at revision 1.2.2.
Applying patch 1.2.3.sql ... failed. Attempting next alternative.
Applying patch 1.2.3a.sql ... failed!
psql:dba/patches/1.2.3a.sql:8: ERROR: must be owner of relation role_member
psql:dba/patches/1.2.3a.sql:9: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:10: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:11: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:13: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:14: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:16: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:17: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:18: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:19: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:21: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:22: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:24: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:25: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:27: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:28: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:29: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:30: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:32: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:33: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:35: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:36: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:37: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:38: ERROR: current transaction is aborted, commands ignored until end of transaction block
psql:dba/patches/1.2.3a.sql:40: ERROR: current transaction is aborted, commands ignored until end of transaction block
there is no transaction in progress
==> No further patches will be attempted!
No patches were applied.
Supported locales updated.
CalDAV functions updated.
RRULE functions updated.
WARNING: no privileges were granted for "collection"
WARNING: no privileges were granted for "caldav_data"
WARNING: no privileges were granted for "calendar_item"
WARNING: no privileges were granted for "relationship"
WARNING: no privileges were granted for "locks"
WARNING: no privileges were granted for "property"
WARNING: no privileges were granted for "freebusy_ticket"
WARNING: no privileges were granted for "usr"
WARNING: no privileges were granted for "usr_setting"
WARNING: no privileges were granted for "roles"
WARNING: no privileges were granted for "role_member"
WARNING: no privileges were granted for "session"
WARNING: no privileges were granted for "tmp_password"
WARNING: no privileges were granted for "dav_resource"
WARNING: no privileges were granted for "group_member"
WARNING: no privileges were granted for "principal"
WARNING: no privileges were granted for "privilege"
WARNING: no privileges were granted for "relationship_type"
WARNING: no privileges were granted for "relationship_type_rt_id_seq"
WARNING: no privileges were granted for "dav_id_seq"
WARNING: no privileges were granted for "usr_user_no_seq"
WARNING: no privileges were granted for "roles_role_no_seq"
WARNING: no privileges were granted for "session_session_id_seq"
WARNING: no privileges were granted for "dav_resource_type_resource_type_id_seq"
WARNING: no privileges were granted for "principal_principal_id_seq"
WARNING: no privileges were granted for "principal_type_principal_type_id_seq"
WARNING: no privileges were granted for "time_zone"
WARNING: no privileges were granted for "supported_locales"
WARNING: no privileges were granted for "awl_db_revision"
WARNING: no privileges were granted for "dav_resource_type"
WARNING: no privileges were granted for "principal_type"
Database permissions updated.
Help :)
Ok, forget about my previous
Ok, forget about my previous post...
Didn't know I had to "su postgres" before running the update-davical-database command :)
I now too have my iPhone working with Davical!! Awesome!!