[CalendarServer-users] Multi-user XMLDirectoryService

[Cyrus Daboo]

Hi Alan,
Points well taken. Some comments below:

--On March 20, 2008 3:11:12 PM +0200 Alan Levin <alan at futureperfect.co.za> 
wrote:

>> I've been playing around with multi-user access under the
>> XMLDirectoryService and had the following questions:
>
> We've been playing around with this for over 18 months and I apologise
> for any negative sentiment here, but I suggest that Apple have not
> been very helpful in this project. Cyrus, maybe you can tell us a
> little about how your time is spent on this?

Obviously I can't describe in any detail specifics of what is happening at 
Apple, but rest assured CalendarServer is an important product for us. 
Remember, the code you see on MacOSForge is what we have in OS X Server.

> I've been following this list since Aug 2006 and last year I was
> disappointed that we had to wait for Leopard to make use of this
> software. Now that I've installed Leopard and spent many hours playing
> with the config files I have lost confidence in this project.

CalendarServer obviously works best with Leopard where the setup and 
configuration really is minimal when tied to the directory service. There 
has not been a lot of work on the "static" XML accounts directory piece. 
Right now that is mainly used for doing unit testing etc.

> There is no doubt that the world needs a good calendar server as MS
> Exchange seems to be the only viable option (and I cannot bring myself
> to using it for clients - we just do not like supporting the MS
> platform). Zimbra seems to be a potential alternative but too
> expensive. DAViCal looks interesting but really just experimental.

Some points (this is written in my role as one of the CalDAV spec 
co-authors): CalDAV is still a relatively new protocol. It is still in some 
flux with some major changes expected to the scheduling model (the 
specification for which is still only a "draft"). As we and others start to 
deploy this we gain experience of what the "missing pieces" are. Bear in 
mind that at the time CalDAV was a "pragmatic" solution to several failed 
attempts to define a standards-based calendar protocol. We started with the 
goal of putting the minimal pieces together to give a protocol that would 
be quick to implement.

The good news is that there are now a lot of vendors (certainly on the 
server side) implementing this stuff and a lot of momentum behind it. On 
going work in the Calendaring and Scheduling Consortium (of which Apple is 
of course a member) is helping to address the missing pieces of the 
protocol via extensions. Of course this will take some time to do, but in 
the meantime we should still have a viable solution.

> Gerald asks superb questions, and definitely the same position we're
> in right now:
>
>> - Is it possible to allow users to access the calendar of other
>> users? Either read-only or read-write but without sharing
>> credentials. I can see how this can be done using <location> via
>> <proxies>, but can it be done directly as a user? Or do I need to
>> hack it using a resource or location? Is there a recommended way of
>> doing this?
>>
>> - What's the difference between a resource and a location?
>>
>> - What's the meaning of the <password> field for groups, locations
>> and resources?
>>
>> - Under <proxies>, what are valid <member type=... values and what's
>> their meaning? Is this where I can use groups?
>
> His questions reflect some other observations:
> - Lacking of documentations

Yes - we need more documentation on the XML directory setup.

> - If you search apples web site for calendarserver = no results

To be fair I did get 186 hits when I searched for "calendar server". Also, 
Apple's site is geared towards "iCal Server" which is what Calendar Server 
is called in Leopard OS X Server.

> - After more than 2 years, this is simply not scalable in it's current
> form

Can you discuss your scaleability issues? We do want to hear about these 
concerns and experiences so we can try and address them (and we certainly 
DO want to address them).

> - The project makes use of outdated or bloated components

Which ones in particular?

> I really hope that there is a way to salvage this. The idea in
> principle is superb.

Something that will be happening soon (and I know I promised this a few 
months back): I have been working on an open source toolset that will allow 
command-line management of key features such as access control and 
delegates/proxies. These will allow setting up of shared calendars etc 
without having to use iCal or being tied to the OD directory service. There 
is also a basic tool to manage the XML directory file too. Simple actions 
such as "list users", "add user", "delete user" etc. The goal is to build 
that up into something that will avoid the need to ever edit the XML file 
directly.

Hopefully this will help in the short term and provide a basis for people 
to build e.g. web-based administration tools using this code on the back 
end to provide better administration for the open source users.

-- 
Cyrus Daboo