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. "
Now all we need to do is get Microsoft to adopt the GroupDAV protocol in Exchange/Outlook.
I feel confident this can be done on February 30th of this year.
I'm a big tall mofo.
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?
How will this get me laid?
And this lack of a GroupWare standard is EXACTLY why organizations like mine (state government) still turn to MS.
If we could get an opensource standard that worked with exiting MS standards then we would switch, if for nothing else then price alone.
It's when everyone dresses alike, sorta like Garanimals.
Not, uh, that I would know what Garanimals is.
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.
You're joking, right? Open source supports the open standards when Exchange uses them.
For instance, you can use active directory as a regular LDAP instance (albiet with funny cn= syntax)
And you can access email boxes as IMAP folders.
In fact, most of the iCal processing is done by outlook and just stored in mail folder (accessible via IMAP). In fact, some people have actually gotten calendaring working with open source software via Exchange.
The only parts that aren't supported are those that aren't open. For instance, the MAPI messaging that exchange can do and those wonky objects in Active Directory that you can't access via the LDAP interface.
Why don't people finish things that have already been started, such as CAP (Calendar Access Protocol).
I'd have to disagree. An open standard is a replacement for Exchange. Perhaps you need a method for connecting outlook to your groupware server, but I see little reason why a groupware server needs to talk exchange.
Before businesses widely adopted SMTP as a standard mail protocol there were all the crappy proprietary mail standards that didn't inter-operate. They all died the long death as people wanted to talk to each other across the internet. I think the same thing will happen with groupware. Until now there hasn't been a standard (or at least an accepted standard) for client/server to talk to each other. The best we've got is iCal, and that's really calendaring only.
AccountKiller
That's great, another standard. But, this one is different because it is supported by Citadel? OpenGroupware and Kontact. These aren't mainstrean groupware systems. In fact all of them combined don't have enough users to establish yet another "standard".
The fact is that there are already more than enough standards out there. What needs to happen is for the groupware systems to start thinning the crowd of standards and settle on a limited set. And, to those that would say that GroupDav is just that, please, Until the likes of Exchange, GroupWise, and Notes include it and Oulook Express and CW have it built in, it is just "Yet Another Standard".
Agreed.
For me the problem isn't Exchange. It's Oulook. People want to use outlook. They don't give a flying frack what it connects to but they want the useabilty of Outlook.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
so if you say microsoft is a standard (ok, its used by a lot of ppl, but a standard is by definition something from an upper committee like iso or rfc or din, not a single firm itself)
I've got terrible news for most Slashdotters, that isn't the definition of a standard. The fact that many Microsoft products, such as Exchange, are used by more people and organizations than any other available product makes those Microsoft products the de facto standard. This will naturally come as a shock but, that doesn't change the fact that Microsoft Exchange is the de facto standard in GroupWare applications.
You can brand me a heretic and mod me down but that won't change the facts or the standard.
It's good to see that someone is trying to invent a solution to this, but it really is only part of the problem.
OSS is all about choice. Choice is a good thing! Unfortunatly it lends itself to 100 different programmers approaching the same problem 100 different near-incompatibile ways. This is the downside of choice - people are not always going to agree on how to do something (read: almost never agree). This can be seen all over the place, noteably in programs designed for X (think KDE vs GNOME) - not as bad as it used to be, but it's still quirky as hell if you want to run applications from one group in the other.
It would be nice if we could say "screw choice, we need a BDFL" for at least a few essential pieces of glue.
Now, fast forward to Redmond. Microsoft applications are almost always tightly interoperable because there *isn't* choice. By this, I mean the group is working toward a single vision of how the operating system should be. The result (os vulnerabilities aside) is a more productive environment where most programs can interchange data very easily. This couldn't work without a certain amount of forced regulation.
BeauHD. Worst editor since kdawson.
The GroupDAV standard is nice and simple, and it ought to be easy enough to implement. However, it's lacking in various useful features. For instance,
Due to this reasons the client SHOULD store alarms locally and SHOULD NOT transmit them to server. The server is MAY reject iCalendar resources containing alarms but MUST signal that using a proper error code.
Woo. I use a GroupDAV server to store my calendar information from my desktop. While I'm on the road, I synchronise my PDA against it. Then I have to go through every event to reset the alarms, since otherwise I don't get any warning about them. Excellent.
Clients SHOULD not post recurring tasks to the server.
I mean, come on.
To allow the client to search for UIDs stored in the server, the server would need to expose the UID as a WebDAV property for use in DASL queries. While this is possible in some implementations (eg OpenGroupware.org ZideStore) it would complicate basic implementations significantly.
Yeah, I can see that making synchronisation fun.
The standard is littered with "This is difficult, so it's not implemented". That's fine - it results in a lightweight specification that's easy to implement, and in many cases it may well be good enough. But it's not appropriate for this to be the standard for open source groupware. It's missing too much functionality. Trying to sell it as a solution for competing with existing groupware solutions is just insane.
"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...
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.