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. "
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.
If MS were to adopt this protocol, it would become GroupDAV.NET, with extra-special "features" added that "our customers demand." These features of course would not be compatible with existing open-source programs, nor would they be compliant with the standard, and guess who would win the ensuing "betamax" war?
As another poster has pointed out, they are wedded to MS in unholy matrimony because of Exchange. Don't think for a minute that MS will give up one of their better lock-ins in the name of "compatibility." Just like when one political party talks about "bipartisanship" and actually means "cave in to our demands," when MS talks about compatibility and "open standards" what they really mean is "do it our way, or we'll tell you where to go today."
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
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.
Just because it doesn't work now doesn't mean it won't in the future. You have to start somewhere. The reason everything has become divided on this front is probably due to there not being a good standard to rely on. Now that we have that maybe it can be implemented on those apps that most people use. So hold your judgement until you see what happens in the future.
Kyle
http://www.unlogikal.net/
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.
Aside from Outlook/Exchange, all other groupware implementations are total crap. OpenGroupware.org is a noble effort, but it has the absolute worst interface I've ever seen. Evolution has far too many dependencies on the Gnome library labryinth for it even to be worth consideration. Mail.app is flaky. iCalendar works, but has some severe limitations to make it useful as a groupware product in a production environment.
My company (Mac OS X- and Linux-based systems) has been looking at this problem for awhile. We've got an internal system that works ok, but it's only marginally better than the systems listed above.
GroupDAV is at least an effort to get cross-platform, cross-application groupware set up. It reduces the complexity from a 2N problem to an N problem - if I find a good server or client implementation, I can write the other half of it and watch it go.
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.
I've been bitching about that for a LONG time now, and Sunbird/etc has really progressed no further. It can't even read its *own* invites sometimes.
This was a huge issue when I was trying to move a small business off of Outlook. The integrated calendar is the main thing that kept them locked into Outlook. No Exchange, mind you, just the simple Outlook calendaring. WebDAV calendars/etc just didn't cut it. Can't schedule things like, oh, conference rooms. Can't apply designate rights. Lots of things that Outlook *can* do.
Half of Outlook's functionality is dependent on an Exchange server (calendar sharing, out-of-office notification, etc.)
Why yes, I AM a rocket scientist!
You two are talking about different senses of the word "standard": one is the sense of "something that a lot of people use", the other is the sense of "a protocol or API that a lot of people code to". Among standards, we distinguish "de facto standards" and "official standards", where it is generally understood that something is an official standard unless you qualify it explicitly (just like it is usually understood that birds can fly unless you specifically talk about flightless birds).
Exchange is a "de facto standard" in the sense that it's a product a lot of people use. But it isn't a "standard" in the sense of being something that has been defined in writing that people can write interoperable products for.
Now, Win32 and Java are "de facto standard" in the sense of being something well-defined. One may or may not choose to re-implement or interoperate with them, but at least that is something one can talk about. For Exchange, there simply is nothing one can target, it is just a proprietary piece of software.
So, harping on the fact that 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 since we can't use Exchange's protocols.
What FOSS can and should do is make FOSS alternatives to Exchange and Outlook look and feel as close as possible to Microsoft products so that administrators and users will accept it more easily, and that interoperate as much as possible with existing Exchange servers and Outlook clients. And that's exactly what they are doing. So, the fact that Exchange is a "de facto standard" isn't big "terrible" news to Slashdotters, it is something that has already been incorporated into FOSS plans for Exchange alternatives to the degree technically possible.