[CalendarServer-users] Multi-user XMLDirectoryService

[Alan Levin]

Hi Cyrus,

On 20 Mar 2008, at 4:10 PM, Cyrus Daboo wrote:
> Points well taken. Some comments below:

Thanks. I wish they were closer to the point.

> 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.

As mentioned that's what I've been doing for the past 18 months. We  
need more info from you before I can rest assured. I was hoping that  
you would be able to tell us that you are full time assigned to this,  
together with a team of other specialists that you can call on at any  
time. Plus a QT available on demand.  Is this a part time job for you  
or are you dedicated?

>> 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.

This is as I expected and believe we have successfully installed a few  
weeks ago. As mentioned I've waited 9 months for Leopard which I now  
have installed up to date and spent 2 weeks trying with the XML files.  
More specifically we are using the "XMLDirectoryService:" Hence our  
questions in this regard. If you have a better advice for  
implementation please say so.

> 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.

Understood. Although this has not been, "quick to implement", simple,  
or any way useful. The very old way of storing ics files on a webdav  
server was better than what I see now.

> 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.

Please explain how you see this as viable. All I can do is see my  
calendar on a server, same as counterparts. We did manage to get  
'resources' working but you still do not answer the critical questions:

>> 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?

???

>> - 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).

Please start with Geralds unanswered questions. They are the main the  
reason why I stated this.

> 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.

If I could get the XML file to work - if I can try to understand it -  
then I expect this will sound like good news.

> 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.

I'm sorry this is no help at all, please go back to Gerald questions  
and I suspect if we can all understand the answers and implement  
changes to make this work (even partially), then we will be onto  
something.

Thanks,

Alan





-- 
Alan Levin
Tel: +27 21 409-7997