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. "
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?
--
make install -not war
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?
Although this is a great step in the right direction, I still think is only going to be limited adoption until open source supports MS Exchange. Outlook/Exchange is so common in companies (big users of groupware) that open source is hurting itself by not supporting it.
I store my recipes online (the way nature intended)
http://www.jwz.org/doc/groupware.html Exactly
I wouldn't bet on that. With groupware, almost more than any other application, usability typically trumps prices as a user requirement.
Not at all! Only HULA *H*elps *U* get *LA*id
http://www.hula-project.org/
But then I think you knew that!
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:
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.
Tired of FB/Google censorship? Visit UNCENSORED!
Perhaps the goal is to get a complete 'Groupware' server, and client out the door with a little functionality as possible. Then slowly add that functionality into the products, instead of speding the first three years of the project hammering out an exacting spec. that takes another five years to implement and debug.
Think of it sort of like a bottom-up design to a 'Groupware' standard.
How well this approach works will be interesting to follow.
But no matter what, if it doesn't have a flawless MS Exchange mailboxe import feature it will be useless.
The only good thing about Exchange/Outlook is being able to invite people to meetings.
Maybe they should start with a kickass scheduling server and client.
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.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
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
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.
you know what would make me happy? you know what i would find sexy? if there were a viable F/OSS alternative to microsoft exchange with native cross-platform clients. that would make me so happy/sexy i'd probably drop trou and start stroking in my cube immediately.
nice rant from JWZ, committee-driven requirements are all ha-ha-funny, and management are brainless dicks who will never use the features anyway etc. etc. etc. but the fact remains that the outlook/exchange combo is the gnarly root of the rotting impacted tooth that is the microsoft software stack in businesses. a viable alternative must exist before we can yank that sucker out.
that said, there were a lot of useful suggestions in JWZ's article. i agree the place to start is to get calendaring and meeting invites down cold. but at some point you do need to add some straightforward project management / workflow crap.
outlook / exchange presents these functions interoperably through a single integrated interface that business-types are comfortable with, and that should be the goal of a groupware app. this need not contravene "the unix way is to do one thing well" philosophy - the "one thing" that such a client should do well is provide a unified interface to these groupware functions, which should work together.
pr0n - keeping monitor glass spotless since 1981.
> 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.
:-) I can only speak for OGo by saying that the Sunbird GroupDAV efforts wouldn't have been started if Sunbird CalDAV support would have already been available.
I think no one believes that and the other comment regarding that is incorrect. GroupDAV perfectly allows for clients to push cycles and alarms, its no different from CalDAV here.
The difference is that GroupDAV can be used with servers which do _not_ provide that OR provide it in a different way from iCalendar - which is very common for recurrences. CalDAV ignores them, which is perfectly OK for its goals.
Again: GroupDAV is _not_ a replacement for CalDAV, its something else.
I very much welcome that you started CalDAV support in Sunbird and I'm looking forward to it. GroupDAV started earlier because nothing else was available and had working connectors for Kontact in October and a first beta for Evolution in December.
So we were a bit faster, sorry about that
But maybe I'm missing something here. It's happened before.
Mike