Users who are members of a wiki can directly "subscribe" to the wiki calendar via a special sharing mode that involves simply clicking a link in the wiki calendar - that will "bind" the wiki calendar into the user's calendar home where it appears as if it were a calendar shared by an individual. So I asked the list, and it seems the best ways to share calendars with groups instead of inviting every member of the group directly are: Are you using icalserver standalone or as part of OS X server? With OS X server the wiki feature does offer a way to manage group calendars via the wiki group membership. So I added an existing email address to the group's OD record, but the problem is that it's the user who receive the invitation and must accept it in iCal. In Open Directory, groups don't have email addresses by default, so I said: "hey, let's add one with dscl!". Why? Because even if the invitation is not sent by email, the user or contact that is going to get the invitation must have an email address. I need to share calendar collections from iCal Server to groups, but sadly, with CalDAV it doesn't work. So, the message is: if you want to test bad behaviour against a CalDAV implementation, Google Calendar or CGP are quite good candidates. I really don't know why they are doing this, but if you create a calendar in your own account, it shouldn't show up as a proxy since it's one of your own calendars. When you add a new calendar collection to Google Calendar, it show up as a proxy.It didn't even have a DAV principals collection! CommuniGate Pro returns a "HTTP/1.1 500 mailbox with this name already exists" status code, with the body as HTML! Again, if a MKCALENDAR fails because the URI already exists, it should return a 403 Forbidden code, with a XML body that explains the error.But CommuniGate Pro returns a 200 OK status instead. The CalDAV says that a successful MKCALENDAR request should return a 201 Created status.But CommuniGate Pro and Google Calendar, oh boy! Same thing for Fruux (which uses the SabreDAV framework). Kerio don't support as many extensions as iCal Server, but they follow the RFCs quite well. It's really the best CalDAV implementation out there. ![]() I have nothing bad to say about iCal Server. When I test new stuff and want to see the behaviour, I test against: I'm contributing a lot of code to cdav-connector, a CalDAV/CardDAV library for Hava.
0 Comments
Leave a Reply. |