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. "

Comments

untouched versions

[Doc Ruby]

DAV is versioning, especially relevant to concurrency in groups. How does GroupDAV model that kind of versioning? And how are our existing, divergent client apps supposed to represent that?

Product support

[Anonymous Coward]

And it works on Groupwise, Outlook/Exchange, Mail.app... what, it doesn't work on the software that most people actually use? Then who's going to use it outside of a few small Linux-only dev shops?

Or less sarcastically, what's been the effort on getting large vendors to support the new standard?

Re:Question number one

[alachyr]

http://www.jwz.org/doc/groupware.html Exactly

Re:Yet another "standard".

[IGnatius T Foobar]

These aren't mainstrean groupware systems. In fact all of them combined don't have enough users to establish yet another "standard".

Well, here's how we're viewing it from inside the GroupDAV alliance.
We feel that all of the efforts that have been made up to this point have failed because of one or more of the following reasons:

• Too complicated to implement (as was the case with CAP, which nobody has even tried to implement, and CalDAV, which exists only in a few vaporware implementation). GroupDAV is designed to be easy to implement yet cover the most common use cases: connecting address books, calendars, task lists, etc. to your server. We've proven that it's easy to implement -- every project that has implemented it so far was able to get an initial version up and running in just a couple of days.
• Too specific to one product or project. GroupDAV solves this problem by sticking to the standards: iCalendar for calendar and task list data, vCard for address book data, HTTP for authentication and transport.
• All talk, no proof of concept. GroupDAV has proven that's not the case here, because we have at least two clients and two servers up and running today, with more on the way.

A rising tide lifts all ships. If the concensus we've begun here continues to expand to become a de jure standard, it will spell the beginning of the end for proprietary groupware connectors.

Re:A naive question

[morzel]

Why am I not hearing about Lotus Notes on linux? Did something change while my back was turned?

(I'm assuming you're talking about the client application, since for the Domino server Linux is one of the target platforms.)

For one: the native unix Notes client implementation (version 4.5 was the last) sucked tennisballs through a garden hose. It was justly terminated: why supporting a unix client that wasn't even used by 1% of all clients?

Secondly: with Notes release 5, for standard groupware stuff the Notes client ran acceptably in a Wine environment. Some guys at IBM even made a special Wine package for notes (NUL - Notes under Linux) -- remember that R5 went gold in 1999, when Lotus wasn't part of IBM and Linux wasn't all the brouhaha it is now.

Thirdly: from the most recent release (6.5), all the groupware functionalities can be accessed using Domino Web Access (formerly known as iNotes), and IBM went through great lenghts to make Mozilla a supported platform for this. Think webmail on steroids.

Lastly: IBM is pushing the "Workplace" technology, centralizing everything on beefy servers and provide all the technologies on-line, based on heaps and heaps of Java. Lotus Notes is part of this transition, and my guess is that with the release after the upcoming release (R7 is currently in public beta) the Notes client as we know it ceases to exist and is replaced by something that is based on Eclipse.

Disclaimer: I'm a certified Notes/Java developer.

Unlike what now?

[Mike Shaver]

Unlike CAP and CalDAV, the GroupDAV effort is backed by real code that works today.

Huh. I participated in an interop in January in which we had CalDAV implementations from 3 different vendors interoperate pretty darned well. (Where they didn't the limitations were almost exclusively due to differences in handling of various ICS details, which problem plagues all ICS-based calendaring efforts, from CAP to GroupDAV and beyond.)

In addition to the IETF-style interop checklist we ran over the course of two sessions, we also had demonstrations of things like Sunbird and Outlook sharing a calendar on the basis of a CalDAV adapter for Exchange (written by Oracle). Is this code that's not real? That would make me and others sad, because we spent a fair bit of time writing this code, and it sure seemed real when we ran it and shared calendars!

I'm also interested, as someone who works on Sunbird pretty much every day, to hear more about this "Sunbird connector" that is in beta. I haven't seen it yet, and we're always looking for useful new providers -- where is the beta testing being done? (The discussion of the implementations on the groupdav.org site confused me -- why would you need to have a server as a goal for a client-side connector? Isn't the whole point of a pseudo-standard like GroupDAV that you code to the protocol and not the peer?)

Mike

Re:don't muddy the waters

[Undertaker43017]

While I agree with this statement:
"You two are talking about different senses of the word "standard":"

I don't agree with this:
"...Exchange is a "de-facto standard" is useless in the context of this discussion: the fact that lots of people use it is not relevant to the question of what kinds of protocols FOSS groupware should use ..."

It most certainly is relevant, because like it or not most users, don't have a clue what Exchange is, but they sure like Outlook and the functionality that "it" provides. Have you ever tried to change an Outlook user away from Exchange/Outlook? 9 out of 10 times, they will complain (probably 10 out of 10 will complain, but 1 may "accept" his new environment).

So that means for FOSS groupware servers to be widely successful they are going to have to support the Exchange protocol, and integrate nicely with Outlook. MS has no reason to support an open groupware standard for Outlook, because then their "value add" goes away.