Lisa, Here's some feedback on what I think it would take to build a CalDAV server on top of Slide. I'll be referencing parts of the spec here.
"5 - CalDAV defines the following new resource types for use in calendar repositories" Some of these will take more work than others. None seem too hard, but some have some rather odd requirements that need clarification. For instance, should itip-inbox collections inside calendars that are not inside of calendar-collections be deleteable? "5.7 - CalDAV server is responsible for parsing incoming REPLY messages and adding attendee information to events." This should be doable. Slide has a nice event framework that should simplify this type of requirement. "7 - In addition, certain properties are required on calendars to link to principal resources." -and- "13 - All these properties SHOULD exist on every principal if the server supports CalDAV anywhere in its namespace." This one could be a problem. Slide doesn't treat user stores any different from file stores, so the properties available for a particular resource are dependent on the capabilities of the backend Store. For instance, Slide can use LDAP for storing users, so to be CalDAV compliant the LDAP repository would have to be modified to expose the necessary properties to Slide. Since this isn't something Slide can guarantee, this could be an issue. "8 - Since a calendar resource of type text/calendar has properties which duplicate some of its internal state, it's the server's responsibility to keep those consistent somehow." Again, the event framework should help with this, and Slide already has some support for parsing internal properties of uploaded documents. What would be really helpful is an iCal library written in Java with a license that's useable by the ASF. That would save a lot of time, especially if Slide implements a CalDAV client API. "9.1 - SCHEDULE Method for WebDAV" The only really complicated thing here is fanout, I think. There's a lot to scheduling, though, so this is a big chunk to handle. "14 - A CalDAV server MUST also support the set of calendar-specific privileges defined in this section." Slide's security implementation is extensible, so I don't see any big barrier to this other than the work required to support more complicated privileges (such as view-free-busy). "15 - This section defines the reports which a CalDAV server MUST support." Other than handling recurrences this isn't particularly bad, it's just going to be a bit of work. That's about it. Sorry it took so long to get this reply out (that's a rather long document you've put together ;) ). Here are a few things that I think would help encourage a Slide CalDAV server: 1. A working client, especially a test suite. It's going to be hard to verify functionality otherwise. On a personal note, I use Evolution at home and Groupwise at work, so if you can get Novell to support this (especially with Groupwise) I'd be much more inspired to work on it :). 2. An iCal library. A lot of the functionality required by the spec involves parsing and modifying iCal files, so it would speed things if there was an existing piece of work here. 3. Another developer or two. I'm interested in this because I like the topic and I think it's a good thing to do, however I don't have an itch to scratch here. Unless someone else can pick this up too I doubt I'll have the time to implement anything useful. -James On Fri, 2004-10-15 at 16:01, Lisa Dusseault wrote: > I'm doing some investigation of possible open source server > implementations of CalDAV > <http://www.ietf.org/internet-drafts/draft-dusseault-caldav-02.txt>. > > - In the commercial area we've seen implementations started by Oracle > and definite interest by IBM. > - In open source, Redhat is considering working on it sometime soon, > as is University of Washington, but as far as I know they haven't > started yet. > > Has anybody thought of adding this to Slide? It's a natural fit since > the biggest requirement for CalDAV is support for WebDAV + ACL. > > Lisa --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
