Slashdot Mirror
GroupDAV: Standardizing Groupware
IGnatius T Foobar writes "There are lots of open source groupware products out there, but the perpetual problem has always been that we don't have a single, unified standard protocol to connect open source groupware clients to open source groupware servers. GroupDAV changes all that. Support for GroupDAV now exists in Citadel, OpenGroupware.org, KDE Kontact, and connectors are currently in beta for Evolution and Mozilla Sunbird. Unlike CAP and CalDAV, the GroupDAV effort is backed by real code that works today. "
Novell is on-board.... They aren't really a small shop.
I didn't know what it was either. Apparently it's software that helps manage to efforts of groups of people, allowing them to collaborate on projects. So it's exactly what's needed for a distributed OSS project. Refer to useability first for some details.
It's not really a choice, licenesing for that costs money, and reverse engineering a constantly changing product is non-trivial
And I believe that Evoloution has an adapter for Exchange2000.
Not that I have much experience, but visiting Slashdot may be entirely the wrong way to go about answering that particular question ...
(For those who think parent is a troll: here's the idea, with relevant bits highlighted)
Due to a recent posting on slashdot I looked up the current status of CalDAV and GroupDAV. There are pros and cons to each. One of the nice things about CalDAV is that someone is already working on a MAPI CalDAV connector for Outlook (http://openconnector.org/). Maybe it could be re-worked for GroupDAV, but right now it's CalDAV. That gives it a big lead in my book. This could easily change of course.
Personally I don't care which one is better right now. I just need software that will make Outlook work with my Unix/Linux servers. I have not doubt Evolution/Sunbird/etc will work with whatever standard becomes popular.
"Exchange only supports SMTP, POP and IMAP because they have to, in order to interact with the rest of the world"
That isn't entirely true. SMTP is needed to interact with the rest of the world, but POP and IMAP is not needed by Exchange/Outlook. These were added for use by third mail clients, that can't talk the native Exchange protocol.
So from that perspective if enough companies are interested in GroupDAV and want to see it supported, but don't want to migrate away from Exchange (for various reasons), perhaps MS could be persuaded to add GroupDAV support. This would at least allow other clients to play, doesn't do much for OSS GroupDAV servers though...
My company was planing on migrating from NT4 domain / Exchange 5.5 / SQL2000 / Win2k desktops to more platform independant solutions - Novell NDS / Groupwise / mix of SQL2k & PostgreSQL / mix of Linux & W2k desktops
The show stopper? PDA synch with shared calendar used by management. The PDAs synch through outlook. Outlook doesn't talk to Groupwise calendaring. Exchange 2003 requires Active Directory. Having AD makes SQL2005 directory integration an option now...
5 crappy PDAs and not wanting to retrain people on a new mail client is directing our infrastructure....*snif*
"Hatred is the coward's revenge for being intimidated"
Despite the name, WebDAV itself does not provide any versioning, thats part of DeltaV, a separate specification.
Concurrency in GroupDAV is handled using HTTP etags which can be used ensure modification consistency. You might want to read the draft.
Thats certainly true, but it doesn't relate to the topic, which is GroupDAV.
Outlook connectivity is completely out of scope for GroupDAV, it explicitly focused on connecting OpenSource software and intends to stay limitied to exactly this.
GroupDAV is irrelevant for all people wanting to use Outlook. It just for making the world better for the (small but increasing number of) people who do not.
You know, there _are_ actually people using Kontact, Evolution and Sunbird. Just because they are not mainstream doesn't imply that this niche doesn't want to have interoperability.
In the _target software of GroupDAV_ which are OpenSource servers and clients, the reason is pretty simple to explain:
CAP requires a major effort to get implemented, mostly because its not HTTP.
The far majority of OpenSource servers have their roots in HTML web interfaces, often done in PHP or Perl. This is why simple HTTP protocols which do not require a degree in being understood are quickly implemented - XML-RPC, RSS, Atom.
GroupDAV is similiar in spirit, intended to be very small and easy to implement. As a bonus it intends to be a good basis to implement an "adult" protocol like CalDAV. Which is a thing the more elaborate groupware servers like OGo will certainly do.
Your observations are correct. The limitations are the result of research on how existing OpenSource groupware servers are implemented.
If you want to make them support some standard, you need to take their requirements into account.
As an example:
"Clients SHOULD not post recurring tasks to the server."
There are few servers which support them! Putting a requirement on this into the draft implies a rewrite/enhancement of 90%+ of the servers which is unrealistic and destroys the goal of having "some" reasonably good standard.
"Trying to sell it as a solution for competing with existing groupware solutions is just insane."
The GroupDAV effort doesn't try this. It tries to increase interoperability between opensource software in a pragmatic way.
It doesn't compete with anything, because there is no standard which covers this niche.
(Also: people have indeed tried to implement CAP, and in fact I believe Groupwise shipped with support for one of the drafts quite some time ago. I do agree that CAP's a bad scene, but you really should be a little more careful with both facts and language if you're going to both represent your efforts and disparage others'.)
If you believe that the "most common use cases" don't include alarm preservation or recurring events, we must be talking to very different users.
If you believe that "sticking to the standards" with iCalendar "solves" the problem of being specific to one product, I submit that you have not spent enough time trying to actually interoperate with other iCalendar-using products. RRULE support (especially BYSETPOS, but also exclusions), VTIMEZONE handling, proper invalidation of PARTSTAT when "significant" changes happen, preservation of X-PROPS and X-PARAMS, alarm semantics, even proper newline behaviour are all stumbling blocks of various heights. GroupDAV itself seems to encourage behaviours that would prevent iCalendar compliance, such as not round-tripping alarm information and recurrences.
Even HTTP doesn't solve it all for you, as has been discussed in some detail recently on the caldav list. It's better than the alternatives, but saying that it "solves the problem" strikes me as pretty naive.
When we started building CalDAV support into Sunbird in December, we had a proof-of-concept server from Oracle to work against, and did, scheduling meetings with other people and interoperating with other (esp. non-CalDAV) clients. We had two servers and two clients at the January interop, plus the Exchange adapter that let us run Sunbird against Exchange and share calendars with Outlook, including basic scheduling. I'm very happy for your project's success in implementing a simple document-sharing collaboration model, but you should really consider raising your standards of research.
All that said, I would be happy to help the author of the "beta" Sunbird GroupDAV connector get themselves checked into mozilla/calendar/providers. It was a pleasant surprise to hear that it was in beta, since I hadn't heard anything of it myself.
Good luck to you!
Mike
No. We just built around the assumption that the majority of servers can't do much but we are fully aware that there are some which are much more capable. Which is why we intentionally plan for an upgrade path to CalDAV which is much more powerful (but also more complex to implement).
From Mozilla CVS, as with all things Sunbird. If you'd like to, you can browse the source for the CalDAV provider on LXR. Sunbird 0.3 will be the first released version with native CalDAV support, but you're welcome to build your own in the interim.
This is the sort of thing that can be trivially discovered by asking in the Sunbird newsgroup or IRC channel, in case you are ever confused in the future about where to find Sunbird source.
You'd have to ask an Oracle representative about their connector; I think some are listed on the CalConnect site.
I don't have much to say to this, I just really enjoyed reading it after the both the initial posting and the Citadel guy's post elsewhere in this thread decried CalDAV as "vaporware" and "without working code". So I thought I'd quote it so I could read it again and again! CalDAV is relying on, and helping, the Calsify effort to come up with simplified, min-interop subsets of iCalendar, based on input from many implementors of many products, rather than inventing our own subset based on just the products we've been directly involved with. I believe there is a BOF on this topic at the IETF in Minnesota shortly, if your group would like to participate in it.Mike