DAViCal 0.9.6.1 release
Well, it seems that there were few problems with the pre-release of DAViCal I pushed out last week, so 0.9.6 is out now.
The full release notes are on the wiki. The biggest change is that this release now supports free/busy using the method defined in the draft scheduling extensions for CalDAV, so it's possible to schedule meetings with Sunbird/Lightning or iCal, and possibly other clients if they support that.
Now I can concentrate on getting some paid work done for a few weeks before I start on the next stage.
Updated
After release I discovered that due to the changed behaviour of DAViCal, interoperation with Mozilla Sunbird/Lightning 0.8 was no longer working. A new 0.9.6.1 version has been released to resolve this issue.
![[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}
Great Work
Two words : thank you ! DAViCal is the only "light" (i.e. not Java :p) implementation of a CalDAV server, and this is the first reason I'm using it. Anyway, I'll install it asap :)
createdb template0 vs template1
I have template1 configured locally to include plpgsql. When I run
su - postgres -c 'bash -x /usr/share/davical/dba/create-database.sh'
It seems to
+ createdb --encoding UTF8 --template template0 --owner davical_dba davical
Later:
+ psql -U postgres -qAt -c 'SELECT lanname FROM pg_language;' template1
Which FPs on plpgsql, which isn't applied to template0 and thus actually isn't applied to davical either.
Changing the only instance of template0 to template1 works perfectly.
http://www.postgresql.org/docs/8.1/static/manage-ag-templatedbs.html
Thanks!
Thanks for the report.
It's intended that the database be created from template0, to ensure a known starting point... my mistake was in referring to template1 at all :-)
I've changed the test for the presence of the language to be against "${DBNAME}" instead of template1, and that should work a lot better.
Cheers,
Andrew.
I updated from a 0.9.5 RSCDS
I updated from a 0.9.5 RSCDS release. Thanks for your work on this! However, a few issues:
- Still running postgres 8.1.4, and the rrules SQL isn't compatible.
- Not working with iCal or Sunbird for me yet.
The rrules SQL is not yet used
Although I've put a lot of work into the RRULE SQL recently it isn't yet used in DAViCal. It's looking good though, and apart from the fact that it doesn't work against older PostgreSQL (wow! cursors are actually useful in 8.3 :-) it does a good chunk of it's job.
I plan to rewrite some of those functions using arrays, rather than the scrolling cursors from 8.3, and I don't think I will lose much efficiency. As it stands the RRULE implementation in PostgreSQL seems to be faster than the one in PHP, and I'm a lot more confident of it's correctness at this point.
RRULE is a complicated beast, however, and if nothing else having two entirely separate implementations allows me to check them off against each other, and that alone has caught a number of bugs.
As for your problems with iCal and Sunbird, I'm afraid I have no idea what they might be. I assume that you have run the database upgrade script?
If it's possible to get on IRC then visit #davical on irc.oftc.net for some interactive help. Look for lines that have 'QF:' in them in the PHP error log (i.e. the Apache error log unless you redirected it somewhere else). If all else fails then please send me a tcpdump of the communication so I can track it down.
Thanks,
Andrew.
After upgrading the web
After upgrading the web interface is working fine, but I can't connect with iCal ("CalDAV No Calendar Home Error")... I tried to run the dba/update-davical-database script but only got the message
DBI connect('dbname=davical','',...) failed: could not connect to server: No such file or directoryIs the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
at dba/update-davical-database line 207
What to do?
You *do* need to upgrade the database
You will definitely need to upgrade the database, so if you can find the reasons why the upgrade script can't connect, and fix those, before expecting everything to work.
This wiki page detailing the configuration and command-line options for the update-davical-database script is a good place to start from:
http://wiki.davical.org/w/Update-davical-database
Regards,
Andrew McMillan.
upgrade using postgresql 7.4
Hi,
I just updated to 0.9.6.1. Since we are still running postgresql 7.4 I had to:
- change one of the database update patches (1.1.12a)
from
ALTER TABLE collection ADD COLUMN publicly_readable BOOLEAN DEFAULT FALSE;
to
ALTER TABLE collection ADD COLUMN publicly_readable BOOLEAN;
ALTER TABLE collection ALTER COLUMN publicly_readable SET DEFAULT FALSE;
- disable the way the postgresql version is retrieved since 7.4 does not support
E' strings. In connect_configured_database() it now just returns 7.4.
Seems to run fine now.
PostgreSQL 7.4
Yeah.
You can copy each patch to a new patch with an extra letter suffix and that will be attempted after the earlier one fails. I think the last couple of functions in dba/caldav_functions.sql would also need some modifications to work with 7.4 too.
That said, PostgreSQL versions less than 8.1 really aren't supported with DAViCal, though they will work if you muck around with it. You can expect that there will be issues as it's been years since I even had the manuals installed. All development for the last year has been on PostgreSQL 8.3, but I do try and support back as far as 8.1 for the time being.
Cheers,
Andrew.
Groups and Relationships in Davical
Hi,
I'm trying to use groups to link multiple users to a particular user and its calendars. However, I can't figure out how to link the group to anything else.
Is there a primer somewhere that provides more direction than what's currently on the davical wiki and davical.org.
Thanks for a great caldav server!
Davical 0.9.7 with iCal
I've see quite a few people posting on other forums about getting the following error with daviCal >0.9.6 and iCal
iCal ("CalDAV No Calendar Home Error")
My setup:
SuSE 11.1
davical_0.9.7-0
awl-0.36
postgresql-server-8.2.6-0.1
PHP 5.2.6
Kmail, ical, lightening as clients
I had the same problem (also with lightening in thunderbird)... this is what I did to make it work
1) Saw in httpd logs the following error:
PHP Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /usr/share/rscds/inc/caldav-PROPFIND.php on line 785
2) So added/updated the following to the php config in /etc/php5/apache2/php.ini
allow_call_time_pass_reference = On
3) After that I could then Create the calendars in ical again BUT there was no calendar data
4) I added the FULL path to the users "home" dir (https://<Domain>/caldav.php/<name>/<Calhome>/)
NB: you DO need the trailing '/'
5) ALL the calendars are then shown...
Andrew: Can you shed some light on to the following for me please:
1) Why do I need
a) The trailing '/'
b) Why do I now need to add the calendar 2nd level dir to show the cals
c) Why do I need allow_call_time_pass_reference and will it be supported do you think in later PHP versions?
Thanks... Hope you find the above useful.
Ask if you need more info.
iPhone Setup
Odd. I don't have the trailing '/' on my account here. In fact I don't have the calendar either, just:
As for needing 'allow_call_time_pass_reference': unfortunately this is a case where I am trying to span a range of PHP versions. It seems that the way I am calling some core code is not compatible with the future way, but the future way is not possible on those older PHP versions.
If I could track down the exact functions concerned I could probably add some version dependent function definitions, and I will probably do that when the problem starts to bite me as well :-)
Regards,
Andrew.