Mailing List Archive

On Mon, 2009-11-09 at 22:43 +0000, Gavin McCullagh wrote:
> Hi,
>
> We're working out which calendar server alongside a (currently) 500 users
> email setup and CalDAV seems like an option. The other obvious
> linux-based, FOSS solution seems to be Apple's calendar server. I've just
> installed davical as packaged in Ubuntu Karmic (0.9.7-0) this afternoon
> with the ldap hook against an existing kolab setup. This has worked pretty
> well so far. I have a few questions to help me get an idea how practical
> it would be for us to use:
>
> - Has DAViCal been used for medium to large sized organisations? How
> big? I see the docs mention "several hundred staff". Supposing for
> safety we'll grow to a couple of thousand, would we be outside your
> target audience?

I don't really have a lot of knowledge about the size of installations
out there. It's something I'd like to survey at some point to get some
kind of picture.

There is one significant performance gotcha with 0.9.7 with some
calendar proxy support that uses an inefficient query. From 0.9.7.2
there was a config option to disable this, and the issue is in the
process of being designed out in 0.9.8 with a rewrite of the permissions
logic.

There is also a bit of a performance hit for any clients using WebDAV
which I've just been going through with a largish user, but there are
caching workarounds which can be applied to that situation quite easily.

I would like to think that DAViCal will be able to handle a campus of
several thousand, and I am working to implement a number of performance
related features, including the (draft) webdav-sync.


> - Is there a tested or recommended plugin for Outlook which would work
> well with DAViCal? I guess this is a general CalDAV question, but it's
> good to know as we have some outlook addicts.

There's no free one, but ZideOne seems to be the best known. Perhaps
other people can provide some experience here...


> - The web interface seems a little clunky. I mean no offence but it's not
> really neat enough for me to send users toward. I suspect it's mostly
> a question of hiding the bits they wouldn't be interested in and
> steering them straight toward editing personal info and ACLs. It's not
> clear to me why users logging in would need to list all users, report
> bugs or read details of relationships.

Yes, it's definitely clunky :-)

There are a few changes in the pipeline for 0.9.8 but it will still tend
towards the clunky side. It would be relatively easy to pare it down
for a 'normal' user to just a small set of functions they should be able
to see.


> - If calendar clients could set the ACLs themselves, we probably wouldn't
> need to send users to the web interface at all. Sunbird doesn't seem
> able to do that, though I see it's listed as WIP in the wiki but
> Mulberry and iCal aren't supported in. Is there a standard way to set
> ACLs from within the calendar client or are they all doing it
> differently?

There is a standard way, and implementation of support for that has been
waiting for the new permissions logic to land. The new permissions code
is arriving in 0.9.8 and I expect to work on implementing the underlying
DAV ACL methods in 0.9.8.1 or so.


> - When you set an ACL (say allow someone read access), it appears that
> applies to all calendars for a particular user. Is it possible or
> planned to have different ACLs per calendar? I'd personally like a work
> calendar and a private life calendar which needless to say would ideally
> have different permissions.

This is how it is working in HEAD at the moment, with the new
permissions model. I don't recommend playing with HEAD at this point
(there's no UI for setting some of this stuff, so you'd be stuck) unless
you want to get involved with development.


> I realise now that I'm using a slightly old version of davical so perhaps
> some of these questions would be answered if I used more recent packages.

Well, not any released version, but the changes in the pipeline towards
0.9.8 are substantial, and on-track for a pre-christmas release.

Regards,
Andrew McMillan.


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You are the only person to ever get this message.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20091110/5e66b8d9/attachment.pgp>
-------------- next part --------------