Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software

GroupDAV: Standardizing Groupware 150

Posted by CmdrTaco from the everybody-likes-standards-right dept.
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. "
This discussion has been archived. No new comments can be posted.

GroupDAV: Standardizing Groupware More

GroupDAV: Standardizing Groupware

Comments Filter:

  • Good step! (Score:3, Funny)

    by bigtallmofo ( 695287 ) on Thursday February 24, 2005 @02:33PM (#11768603)
    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.
    • If Microsoft adopted it then you wouldn't be able to say... the GroupDAV effort is backed by real code that works today. ...at least not until the third version came out.

    • Re:Good step! (Score:4, Insightful)

      by crimethinker ( 721591 ) on Thursday February 24, 2005 @02:41PM (#11768702)
      My bet would be the 1st of April. Repeat after me, "Embrace and extend."

      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 [slashdot.org], 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

    • This is funny cuz it's true so it should also be +1 insightful.

    • Due to a recent posting on slashdot I looked up the current status of CalDAV and GroupDAV. There are pros and cons to each. One of the nice things about CalDAV is that someone is already working on a MAPI CalDAV connector for Outlook (http://openconnector.org/). Maybe it could be re-worked for GroupDAV, but right now it's CalDAV. That gives it a big lead in my book. This could easily change of course.

      Personally I don't care which one is better right now. I just need software that will make Outlook w
      • 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.

  • untouched versions (Score:5, Interesting)

    by Doc Ruby ( 173196 ) on Thursday February 24, 2005 @02:33PM (#11768606) Homepage Journal
    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?

    • Re:untouched versions (Score:3, Informative)

      by helge5 ( 172721 )
      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.

  • Product support (Score:3, Interesting)

    by Anonymous Coward on Thursday February 24, 2005 @02:35PM (#11768629)
    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:Product support (Score:1, Informative)

      by Anonymous Coward
      Novell is on-board.... They aren't really a small shop.

    • Re:Product support (Score:4, Insightful)

      by FuzzzyLogik ( 592766 ) on Thursday February 24, 2005 @02:47PM (#11768772) Homepage
      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.

    • Re:Product support (Score:1, Insightful)

      by Anonymous Coward
      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 aw
      • 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.

        You forgot the groupware UI nightmare to end all nightmares -- Lotus Notes.

    • Re:Product support (Score:2, Interesting)

      by helge5 ( 172721 )
      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 t

  • Question number one (Score:4, Funny)

    by Anonymous Coward on Thursday February 24, 2005 @02:35PM (#11768643)
    How will this get me laid?

  • Lack of this is keeing us with Microsoft (Score:5, Insightful)

    by Anonymous Coward on Thursday February 24, 2005 @02:36PM (#11768645)
    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.

    • I wouldn't bet on that. With groupware, almost more than any other application, usability typically trumps prices as a user requirement.
    • MS standards

      As with Santa Claus, the Tooth Fairy, and the Easter Bunny, these do not actually exist...

      But as for working with MS products (as opposed to standards), the problem lies with MS. They don't want to open up and of their formats, etc. Why do that when you have a monopoly. It only invites competition.

    • Re:Lack of this is keeing us with Microsoft (Score:5, Informative)

      by bozone ( 113268 ) on Thursday February 24, 2005 @03:54PM (#11769534)

      My company was planing on migrating from NT4 domain / Exchange 5.5 / SQL2000 / Win2k desktops to more platform independant solutions - Novell NDS / Groupwise / mix of SQL2k & PostgreSQL / mix of Linux & W2k desktops

      The show stopper? PDA synch with shared calendar used by management. The PDAs synch through outlook. Outlook doesn't talk to Groupwise calendaring. Exchange 2003 requires Active Directory. Having AD makes SQL2005 directory integration an option now...

      5 crappy PDAs and not wanting to retrain people on a new mail client is directing our infrastructure....*snif*

  • Still needs more... (Score:3, Interesting)

    by chris09876 ( 643289 ) on Thursday February 24, 2005 @02:36PM (#11768650)
    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.

    • Re:Still needs more... (Score:2, Informative)

      by lamp77 ( 147098 )
      It's not really a choice, licenesing for that costs money, and reverse engineering a constantly changing product is non-trivial

      And I believe that Evoloution has an adapter for Exchange2000.

    • Re:Still needs more... (Score:5, Insightful)

      by Wier ( 196038 ) on Thursday February 24, 2005 @02:42PM (#11768712)
      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.
      • 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.

        And lots of 'little features' people use. Like if you assign delegates for an Exchange mailbox, you'd expect them to show up as shared folders for IMAP users, right? No. "Go Buy Outlook/Entourage" is the answer.

        Funny how that works.
      • Where we work the exchange admins (yes we have multiple admins to make sure the email server is working) have turned off IMAP. It's a security problem they say, MAPI and DAV is much safer they claim. I asked one them about IMAP over SSL and he just shrugged.

        • Where we work the exchange admins (yes we have multiple admins to make sure the email server is working) have turned off IMAP. It's a security problem they say, MAPI and DAV is much safer they claim. I asked one them about IMAP over SSL and he just shrugged.

          cock-blocking maneuver against alternative mail clients. they're afraid non-MS software will threaten their turf.

    • Yeah I know at least 2 companies that run nearly 100% unix IT shops that still prefer Outlook pop3 and Exchange 2000.

    • Re:Still needs more... (Score:4, Insightful)

      by Vellmont ( 569020 ) on Thursday February 24, 2005 @02:56PM (#11768865) Homepage
      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.

      • Re:Still needs more... (Score:5, Insightful)

        by nlinecomputers ( 602059 ) on Thursday February 24, 2005 @03:03PM (#11768935)
        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.

        • Re:Still needs more... (Score:2, Insightful)

          by Moofie ( 22272 )
          Half of Outlook's functionality is dependent on an Exchange server (calendar sharing, out-of-office notification, etc.)

        • Re:Still needs more... (Score:2, Informative)

          by helge5 ( 172721 )
          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 d
      • While I agree that an open standard is great for groupware and for companies that are "open" to using something, cheaper, better and more flexible, it will be really hard to break the entrenched defacto standard of Exchange.

        I haven't meet an Exchange administrator that didn't complain about it, but I also can't see them embrassing something like this. When you support 10,000+ users on any groupware, migrating those users to something new is a daunting task. Plus after the migration you have to deal with th
        • Oh I'm sure you're right, the 10,000 user orgs aren't going to be the first to adopt this technology. Like every other change in technology they'll be pushed by the smaller organzations adopting it.
          • In this case I can't see the small organization's pushing the big organization's to do anything.

            Groupware servers are mostly only used inside an organization, so interoperability between groupware solutions isn't a pressing concern, certainly not enough to make MS adopt an open standard, IMO. The biggest place this comes up is in mergers, but there are already tools available to allow merging of multiple Exchange servers, or migration to/from other platforms.
    • If only open source could support MS Exchange! But for this to happen, it would be necessary for MS Exchange to actually use an open protocol. MS Exchange is probably one of the most closed products from Microsoft. To the point that, when you connect Outlook and Exchange together, they use their proprietary protocols for everything, even email. Exchange only supports SMTP, POP and IMAP because they have to, in order to interact with the rest of the world. But because there is no standard open protocol for g

      • Re:Still needs more... (Score:4, Informative)

        by Undertaker43017 ( 586306 ) on Thursday February 24, 2005 @03:40PM (#11769366)
        "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...
        • Fair enough, POP and IMAP are not essential to Exchange, contrary to SMTP. My point was that, when MS are given a chance, they go the proprietary route. On groupware, they can do what they want because there is no alternative based on open protocols. So they can lock customers into using Exchange + Outlook with the groupware functionality of both. When we have an open protocol like GroupDAV and applications from other vendors than MS that support it, we will have the choice to get away from Exchange + Outlo

  • Ridiculous.... (Score:3, Insightful)

    by ashpool7 ( 18172 ) on Thursday February 24, 2005 @02:48PM (#11768785) Homepage Journal
    Why don't people finish things that have already been started, such as CAP (Calendar Access Protocol).
    • Yeah, I never understood what happened with CAP. It looks like the spec was 90% finished and then some irreconcilable philosophical flamewar broke out and killed the whole thing. How does that happen?

      • Re:Ridiculous.... (Score:3, Informative)

        by helge5 ( 172721 )
        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.

    • CAP? (Score:2)

      by thule ( 9041 )
      Who cares as long as something happens. From what I can tell so far, CalDAV is a better system, though more complex than GroupDAV. CAP? I wish there was an opensource project years ago. It hasn't happened... so we're on to using DAV. DAV is fine with me. Dunno for sure, but it sounds like I can use Apache with some web app back end (e.g. PHP, java, etc). This is good. I like modular. I like being able to use OpenLDAP and Cyrus IMAP, but being able to choose something else if something better comes
      • At least CAP made sense. This GroupDAV business is just reinventing the wheel in regards to iCalendar.

        "interoperability between iCalendar clients is not ensured"

        Statements like that in the draft are terrible! Nobody will want to integrate this with their standards-compliant iCalendar programs. One of my new assignments is to work on collaborative calendaring... it's tempting to call CAP "complete" and expect upgrades and do some implementation as part of my job.
  • who clog the pipes for a living. Read "phb". I would go into it, but Nat (of Collabra/Netscape) says it best. "Groupware Bad" http://www.jwz.org/doc/groupware.html (yes, the same link that Doc posted on his blog).
  • Now if Microsoft will just support it we will be all set. Oh, wait...

  • Yet another "standard". (Score:4, Insightful)

    by FreeLinux ( 555387 ) on Thursday February 24, 2005 @02:58PM (#11768881)
    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".

    • Re:Yet another "standard". (Score:4, Interesting)

      by IGnatius T Foobar ( 4328 ) on Thursday February 24, 2005 @03:34PM (#11769292) Homepage Journal
      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.

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

        I don't know what "vaporware" implementations are to you, but as one of the authors of a publicly-available CalDAV client, I suspect I should take offense. I've seen CalDAV interoperate, inc

        • > 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 i

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

            That strikes me as a curious statement, given that Stelian announced on Feb 15 [google.com]that he'd "started his work", but that there was "no code yet", and in the same thread mentioned mozilla/calendar/providers, which has hosted development of a CalDAV provider since the middle of December [mozilla.org]. In the same newsgroup,

  • ...Sunbird can grok Outlook meeting invites. I will be so happy when that happens, never having to open Outlook again.

    Seriously, are outlook meeting invites so complicated that they cannot be read outside of outlook? I hate outlook.

    • Keep waiting. :( (Score:3, Insightful)

      by EvilStein ( 414640 )
      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 Outl

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

        I suspect that it can't read its invites because Sunbird has never sent email invitations. Ever. Not even once when it thought you weren't looking.

        I'm sorry that your bitching (always productive) has not driven Sunbird progress to new paroxysms of productivity, but I wasn't able to find anything in the Calendar product in bugzilla.mozilla.org filed by, comm

        • I've never filed any bug reports against it, actually. I'm not a developer, and my comments would go unheard - your "suspect it needs to be marked INVALID" comment proves that.

          Call it "bitching" if you want, but it's still a true statement - the calendar in the Mozilla suite (sunbird/whatever) sorely lacks features that people want.

          Also, when you create a calendar event and then right click it, one of the options is to email invitation.

          Unless this behaviour has changed, I don't know. I don't have Sunbird
        • Why would he file a bug report when it's already listed as a requirement [mozilla.org]? It's not as if grokking Outlook invites is some crazy newfangled idea. The Moz Calendar folks know it needs to be done before Sunbird could be construed to be even remotely useful.
      • I think you are looking for Mozilla Lightning [mozilla.org] (yeah, I know it's only a code name). As am I, and anyone else who knows Outlook users.
    • I'll be happy when Thunderbird's address book can at least import and export vCard records, and has an easy way to send my address as a vCard.

      Address book with no support for import and export of industry standard format = not useful.

      Yes, I know people have hacked together extensions and Perl scripts [mozdev.org]. That's not the point. It should be part of the standard core application.
  • Although I agree standardization is important. We should also consider that it brings certain risks as well. For example, Microsoft Office has become a defacto standard for enterprises to use. By doing this, there were standard exploits for millions of systems. (Hence, the I Love You virus.)

    I am all for standardization, as long as proper security controls are put in place as well.
  • this may seem slightly off-topic, but one of the reasons I love thunderbird is Portable thunderbird. [johnhaller.com] The ability to port the entire application wherever I want is great. You don't just have to run it off a USB-key: I run it off of a shared network drive and it works great (I can access it on any computer easily, and I don't have to use the email application otherwise supplied at work). Now the on-topic part: I think this new groupware standard has the possibility of allowing moderately techno-savvy compute

  • OSS and Software interoperability (Score:4, Insightful)

    by kuzb ( 724081 ) on Thursday February 24, 2005 @03:20PM (#11769117)
    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.
    • OSS doesn't necessarily lead to incompatibility; pretty much everything runs on X and POSIX, even when there are different implementations of various things (consider all the file systems that people use, all of which act the same with respect to programs storing files while being completely different in other ways.

      Things work well when there is no choice in the standards and a lot of choice in the implementations. That's why GroupDAV is a good idea; a wide variety of implementations are agreeing to share

  • Lacking in features (Score:5, Insightful)

    by Fluffy the Cat ( 29157 ) on Thursday February 24, 2005 @03:23PM (#11769155) Homepage
    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.

    • Re:Lacking in features (Score:2, Interesting)

      by Langley ( 1015 )
      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

    • Re:Lacking in features (Score:3, Informative)

      by helge5 ( 172721 )
      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" reason
      • The problem is then you end up with something like WAP -- built on assumptions that current systems can't do much, and thus requiring workarounds by future systems which *are* much more capable but must still remain backwards-compatible.

        • Re:Lacking in features (Score:3, Informative)

          by helge5 ( 172721 )
          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).

  • Unlike what now? (Score:5, Interesting)

    by Mike Shaver ( 7985 ) on Thursday February 24, 2005 @04:11PM (#11769756) Homepage
    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

  • what about hula?
    http://www.novell.com/news/press/archive/2 0 05/02/p r05014.html

    "Feb. 15, 2005 -- Novell today announced the formation of Hula(TM), a new community project to create an open source collaboration server. " ...
    "Hula today includes standards-based e-mail, calendaring and address book functionality that can scale to 250,000 registered users on a single PC with 50,000 simultaneously connected users."

    I haven't had a chance to really look for more info, but this looks promising on the surface.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close