I'm not sure what you mean by "mac front ends". OGo has some support for iCal.app subscriptions and publication. Though iCalendar-over-HTTP is not a protocol which is particularily well suited for calendars which can be written by multiple users. Hopefully Apple will support the CalDAV standard (still in draft) in one of the upcoming releases.
For simple needs an Apache WebDAV server (included in OSX) is sufficient to accomplish the same thing and installing a full OGo server is probably overkill.
The OpenSource version of OGo has been in beta since about one year, previously it was marked trunk, then alpha;-)
The server software itself is developed since about 10 years and was available in stable commercial versions for years (Skyrix 3..4.. currently 5). The first community release, OGo 1.0.0, is expected in May (LinuxTag 2006).
Well, this will happen of course. The nice thing about OpenSource is that you can actually have various solutions targetted to different usages but still reuse a lot of code.
Once all that AJAX stuff in either Zimbra, Hula, xyz _actually works_ in a reliable, usable and cross platform way, OGo is going to add support for that. Yet so far the solutions seem to be far too immature to get real work done.
> Did we already try this? > http://web.archive.org/web/20010223211530/http://w ww.ogsproject.org/ [archive.org] in 2001! It even made it onto/. > http://slashdot.org/articles/01/02/13/1854219.shtm l [slashdot.org]. > Did it go anywhere? no!
GroupDAV is different for two reasons: a) it takes actual implementations into consideration instead of focusing on experiences with one b) it didn't get live as a plea for support, it got live as a protocol with actual implementations The mention effort is certainly worthy, but we came to the conclusion that we need to "do" instead of "propose" to get forward.
> Why not look at something that is useful outside of groupware like building on top of syncML
Because a SyncML client is much more difficult than a GroupDAV client. But SyncML is an important complementary protocol for servers which can support it, just like CalDAV.
> or using xmlrpc/soap
Thats the usual REST vs SOAP argumentation. See the web for reasons why REST approaches are preferred by some.
> or something that is designed for real time data exhange.
Like? Sounds like it would be difficult to implement.
> Then you can hook other applications into your groupware too, not simply share between a handful of groupware platforms. DAV+[i|v]Ca[l|rd] looks nice and suggests supporting existing open standards, but it isn't a real solution.
A solution always has some context. Yes, GroupDAV has a very specific focus and it already is a solution to that.
> * DAV is designed for file storage
Somewhat wrong. Its designed for distributed authoring and versioning as the name suggests.
> * [i|v]Ca[l|rd] is designed for import/export not sharing
Wrong. iCal is initially designed for exchanging scheduling requests. Its used in CalDAV because _all_ OpenSource clients "misuse" it as a storage format.
> * What else uses this "standard"
Nothing else. The specific goal of GroupDAV is almost accomplished. Two of the leading OpenSource groupware clients (Kontact and Groupwise) are already covered and the third (Sunbird) is coming to life soon. Given that GroupDAV is the only protocol which provides that scope, it is supposed to be interesting for other servers as well (certainly the reason why Citadel jumped on the initial OGo effort).
You have the assumption that GroupDAV is the general groupware standard which makes everyone happy. This is wrong. Its just for connecting OpenSource clients to OpenSource servers.
> * Why go for something which is lowest common domininator?
It doesn't focus on the lowest common dominator. HTTP is very much extensible and a GroupDAV goal is to support various levels of iCalendar compatibility.
> * Shouldn't efficiency of the protocol, not the speed of a few apps implementing it be the major considration?
Very much depends on the goal you want to accomplish. Further you suggest that GroupDAV is slow, it isn't. Its fast and highly scalable.
> Side question - has any other groupware suites been invited to participate?
Yes. The postings on Kontact and Evolution support were widely published and the draft states the invite explicitely.
> Like "FOSS Champion" Novell's Groupwise
Groupwise is per definition out of the scope of GroupDAV, its not a FOSS software but a proprietary one. CalDAV will come to the rescue here.
> or Open Souce Crusader IBM's subsiduary Lotus with Notes?
Same like above.
> What about any of these http://sourceforge.net/search/?type_of_search=soft &forum_id=0&group_id=0&atid=0&words=groupware&Sear ch=Search [sourceforge.net]?
The posting on/. was IMHO too early. The draft is version 0.1 with a various issues pending. To get people on the boat you have to deliver solid
Please provide links/announcements on your website - or at least in posting to the CalDAV list, I suppose a lot of people wait for a client to test with! We do not continiously scan the Mozilla sources for incoming CalDAV code for somewhat obvious reasons. We _did_ a lot of research on possibilities before we started the GroupDAV effort in Oct/Nov 2004 and we _are_ tracking the CalDAV list. Nothing was available.
So please acknowledge that your work was (unfortunately) not yet available at the time GroupDAV got implemented. OGo already does participate in both, CalDAV and Icalsify efforts though what we want to accomplish is still different (and complementary).
> 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 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:-) 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.
Notably despite having the V in the core (or ACL or DASL), WebDAV is a huge success and definitely very useful for a very wide range of applications.
Which is somewhat the point of GroupDAV. You _can_ have scheduling REPORTs, full iCal, ACLs or searches in addition to what is specified in the core. We just want to find a common but still useful denominator targetted to the capabilities of existing OpenSource servers.
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).
Yes, this code is not real in the OpenSource community. Where can we download the Sunbird CalDAV support you mention, we dare to get access to this! Where can I buy the Outlook CalDAV connector by Oracle?
There is no Sunbird GroupDAV connector yet, the original poster got this wrong. There are two projects working on it, but nothing has been released so far. Yet there are pretty complete GroupDAV connectors available for Evolution and Kontact (Evo as part of Noodle, Kontact in the main trunk).
Yet please: do not turn this into a CalDAV vs GroupDAV flame war. This is utter nonsense, every GroupDAV connector can be bumbed up to a CalDAV one and every CalDAV server can easily provide GroupDAV access as well possibly reaching a broader client connectivity.
PS: unlike CalDAV GroupDAV tries to restrict ICS requirements to deal with limitations. Pragmatic approach to deal with the real world. A CalDAV server currently requires a full ICS implementation in both the client and the server.
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.
Its very difficult to write Outlook plugins in general, the protocol itself is usually a _very_ minor thing in such an effort. Yes, in theory this could be done. The plugin would need to convert the Outlook MAPI messages to iCalendar or vCard objects. Which is hard.
And no, Kolab currently uses a self invented protocol which uses IMAP4 to access objects and some self-defined XML payload for the object. Implementing GroupDAV (or CalDAV) on top of Kolab is close to impossible (without breaking the whole Kolab concept).
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.
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.
CalDAV and GroupDAV are supposed to be completely complementary.
A GroupDAV event collection is basically supposed to be a CalDAV collection stripped down to the bones. If the server can support CalDAV, it should do so, it can be a GroupDAV (event) server at the same time.
There are no efforts to get it supported by large vendors and there never will be such. This is something CalDAV is working on and will hopefully succeed.
GroupDAV is looking on what is provided and can be implemented by the meriads of _OpenSource_ servers related to calendaring. As a matter of fact this implies certain limits since a lot of servers are just some PHP hacks.
The current state of the art is sharing calendaring information in this environment is using a single large HTTP file. GroupDAV wants to pimp that up while staying compatible with full CalDAV servers (for server which can host it).
Slashdot Mirror
I'm not sure what you mean by "mac front ends". OGo has some support for iCal.app subscriptions and publication. Though iCalendar-over-HTTP is not a protocol which is particularily well suited for calendars which can be written by multiple users. Hopefully Apple will support the CalDAV standard (still in draft) in one of the upcoming releases.
For simple needs an Apache WebDAV server (included in OSX) is sufficient to accomplish the same thing and installing a full OGo server is probably overkill.
Doesn't eGroupware support SyncML synchronisation? I think so.
...
Having a web interface does not imply that servers do not provide other ways to access the data
Thats *0*.8.2-rc3, not 8.2 ...
The OpenSource version of OGo has been in beta since about one year, previously it was marked trunk, then alpha ;-)
The server software itself is developed since about 10 years and was available in stable commercial versions for years (Skyrix 3..4.. currently 5). The first community release, OGo 1.0.0, is expected in May (LinuxTag 2006).
OpenGroupware.org did not spun off PHP, its not even developed in PHP but in Objective-C.
Well, this will happen of course. The nice thing about OpenSource is that you can actually have various solutions targetted to different usages but still reuse a lot of code.
Once all that AJAX stuff in either Zimbra, Hula, xyz _actually works_ in a reliable, usable and cross platform way, OGo is going to add support for that. Yet so far the solutions seem to be far too immature to get real work done.
> Did we already try this? /.
/. was IMHO too early. The draft is version 0.1 with a various issues pending. To get people on the boat you have to deliver solid
> http://web.archive.org/web/20010223211530/http://w ww.ogsproject.org/ [archive.org] in 2001! It even made it onto
> http://slashdot.org/articles/01/02/13/1854219.shtm l [slashdot.org].
> Did it go anywhere? no!
GroupDAV is different for two reasons:
a) it takes actual implementations into consideration instead of focusing on experiences with one
b) it didn't get live as a plea for support, it got live as a protocol with actual implementations
The mention effort is certainly worthy, but we came to the conclusion that we need to "do" instead of "propose" to get forward.
> Why not look at something that is useful outside of groupware like building on top of syncML
Because a SyncML client is much more difficult than a GroupDAV client. But SyncML is an important complementary protocol for servers which can support it, just like CalDAV.
> or using xmlrpc/soap
Thats the usual REST vs SOAP argumentation. See the web for reasons why REST approaches are preferred by some.
> or something that is designed for real time data exhange.
Like? Sounds like it would be difficult to implement.
> Then you can hook other applications into your groupware too, not simply share between a handful of groupware platforms. DAV+[i|v]Ca[l|rd] looks nice and suggests supporting existing open standards, but it isn't a real solution.
A solution always has some context. Yes, GroupDAV has a very specific focus and it already is a solution to that.
> * DAV is designed for file storage
Somewhat wrong. Its designed for distributed authoring and versioning as the name suggests.
> * [i|v]Ca[l|rd] is designed for import/export not sharing
Wrong. iCal is initially designed for exchanging scheduling requests.
Its used in CalDAV because _all_ OpenSource clients "misuse" it as a storage format.
> * What else uses this "standard"
Nothing else. The specific goal of GroupDAV is almost accomplished. Two of the leading OpenSource groupware clients (Kontact and Groupwise) are already covered and the third (Sunbird) is coming to life soon.
Given that GroupDAV is the only protocol which provides that scope, it is supposed to be interesting for other servers as well (certainly the reason why Citadel jumped on the initial OGo effort).
You have the assumption that GroupDAV is the general groupware standard which makes everyone happy. This is wrong. Its just for connecting OpenSource clients to OpenSource servers.
> * Why go for something which is lowest common domininator?
It doesn't focus on the lowest common dominator. HTTP is very much extensible and a GroupDAV goal is to support various levels of iCalendar compatibility.
> * Shouldn't efficiency of the protocol, not the speed of a few apps implementing it be the major considration?
Very much depends on the goal you want to accomplish. Further you suggest that GroupDAV is slow, it isn't. Its fast and highly scalable.
> Side question - has any other groupware suites been invited to participate?
Yes. The postings on Kontact and Evolution support were widely published and the draft states the invite explicitely.
> Like "FOSS Champion" Novell's Groupwise
Groupwise is per definition out of the scope of GroupDAV, its not a FOSS software but a proprietary one.
CalDAV will come to the rescue here.
> or Open Souce Crusader IBM's subsiduary Lotus with Notes?
Same like above.
> What about any of these http://sourceforge.net/search/?type_of_search=soft &forum_id=0&group_id=0&atid=0&words=groupware&Sear ch=Search [sourceforge.net]?
The posting on
Excellent, I very much welcome your work!
Please provide links/announcements on your website - or at least in posting to the CalDAV list, I suppose a lot of people wait for a client to test with! We do not continiously scan the Mozilla sources for incoming CalDAV code for somewhat obvious reasons.
We _did_ a lot of research on possibilities before we started the GroupDAV effort in Oct/Nov 2004 and we _are_ tracking the CalDAV list. Nothing was available.
So please acknowledge that your work was (unfortunately) not yet available at the time GroupDAV got implemented.
OGo already does participate in both, CalDAV and Icalsify efforts though what we want to accomplish is still different (and complementary).
> 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
Notably despite having the V in the core (or ACL or DASL), WebDAV is a huge success and definitely very useful for a very wide range of applications.
Which is somewhat the point of GroupDAV. You _can_ have scheduling REPORTs, full iCal, ACLs or searches in addition to what is specified in the core. We just want to find a common but still useful denominator targetted to the capabilities of existing OpenSource servers.
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).
Yes, this code is not real in the OpenSource community. Where can we download the Sunbird CalDAV support you mention, we dare to get access to this!
Where can I buy the Outlook CalDAV connector by Oracle?
There is no Sunbird GroupDAV connector yet, the original poster got this wrong. There are two projects working on it, but nothing has been released so far.
Yet there are pretty complete GroupDAV connectors available for Evolution and Kontact (Evo as part of Noodle, Kontact in the main trunk).
Yet please: do not turn this into a CalDAV vs GroupDAV flame war. This is utter nonsense, every GroupDAV connector can be bumbed up to a CalDAV one and every CalDAV server can easily provide GroupDAV access as well possibly reaching a broader client connectivity.
PS: unlike CalDAV GroupDAV tries to restrict ICS requirements to deal with limitations. Pragmatic approach to deal with the real world. A CalDAV server currently requires a full ICS implementation in both the client and the server.
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.
Its very difficult to write Outlook plugins in general, the protocol itself is usually a _very_ minor thing in such an effort.
Yes, in theory this could be done. The plugin would need to convert the Outlook MAPI messages to iCalendar or vCard objects. Which is hard.
And no, Kolab currently uses a self invented protocol which uses IMAP4 to access objects and some self-defined XML payload for the object.
Implementing GroupDAV (or CalDAV) on top of Kolab is close to impossible (without breaking the whole Kolab concept).
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.
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.
CalDAV and GroupDAV are supposed to be completely complementary.
A GroupDAV event collection is basically supposed to be a CalDAV collection stripped down to the bones. If the server can support CalDAV, it should do so, it can be a GroupDAV (event) server at the same time.
There are no efforts to get it supported by large vendors and there never will be such. This is something CalDAV is working on and will hopefully succeed.
GroupDAV is looking on what is provided and can be implemented by the meriads of _OpenSource_ servers related to calendaring. As a matter of fact this implies certain limits since a lot of servers are just some PHP hacks.
The current state of the art is sharing calendaring information in this environment is using a single large HTTP file. GroupDAV wants to pimp that up while staying compatible with full CalDAV servers (for server which can host it).
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.