Hi Alan, Points well taken. Some comments below: --On March 20, 2008 3:11:12 PM +0200 Alan Levin <[EMAIL PROTECTED]> 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 _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
