ext Michael Wyraz wrote: >>> i've spent some time with research on different calendaring >>> client/server implementations. I believe that most use proprietary or >>> open but very complex protocols (e.g. CalDav) or protocols that are >>> restricted to read-only access (e.g. WebCal). >>> On the other hand there are some really simple protocols which are >>> not dedicated to calendar access (e.g. xmlrpc or json over http). >>> So the barrier for a developer of a calendar (i.e. a web calendar) to >>> implement a bridge to evoluition is very high. >>> >>> >> hmm. <shameless rant> I've submitted an open source Apache module >> implementation of CalDAV <http://sourceforge.net/projects/modcaldav/>. >> I won't argue that it (implementation) is perfect but I'm inclined to >> say that CalDAV _is_ pretty simple compared to many other new specs >> (i.e. when you don't have to implement the whole http/dav stuff). The >> only exception to this may be the iCalendar spec which is probably >> even too flexible. Fortunately, there's this, many times forked >> libical libary, which we can/should fix. And Evolution is a pretty >> decent calendar client as well (although there are some missing >> features). So with these constraints, I'll doubt that you could >> significantly simplify or improve the situation by creating yet >> another new spec ;-) >> br, jari >> > Ok, the CalDAV spec is not extremely complex. But it depends on iCal, > WebDAV and the CalDAV Spec (which is in fact not a spec but a draft that > still might change). The current CalDAV draft (draft 15) was expired on > March 17, 2007. > The evolution caldav connector is from December 2, 2005 > (ftp://ftp.gnome.org/pub/gnome/sources/evolution-caldav). It implements > the protocol draft version 5 or 6... > CalDAV is already an rfc: <http://www.ietf.org/rfc/rfc4791.txt>. Evolution's CalDAV backend mostly lacks freebusy reports (sure acl handling is totally missing). That said you can still start fixing it fairly easily (I do have some fixes at sf.net). > CalDAV draft has 115 pages. WebDAV consists of at least 7 RFCs, the most > important are together about 300 pages. ICal rfc has about 150 pages. > right, but in OSS world you have many of these implementations, why reinvent the wheel ? > I know about 2 (free) servers (ok, since your mail, i know 3 :-) ) and > maybe 5 clients which supports caldav. Most (all?) of them supports a > subset and all implements different draft versions. > > So in my opinion CalDAV is not a simple protocol. It's a big > all-in-one-approach for calendaring with the cost of high implementation > expense. It will not be implemented in many calendars until stable > caldav-libs (client and server) are available. > I assume quite many of us are trying to boost it ... > I'd prefer a proprietary (in sence of non-standardized, but well > documented) protocol which is easy to implement in a few hours or days. > This gives progammers the opportunity to add client-support to their > calendar servers whitout too much effort. > > regards, > Michael. > > Perhaps I have to stop producing running code, I'm way too slow ;-) br, jari
_______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
