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 _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
