On Wed, 2003-10-15 at 14:19, Maarten Stolte wrote: [snip] > a plugin for Evolution would be just as logical, or maybe even more > logical to build for Kolab, since kolab's specs are open, whereas the > plugin for OGo is the Exchange plugin, which is, at best, a > screenscraper-like solution to get data from Exchange-webaccess > server-like servers. > Mozilla's calendar is pretty cool, but also pretty unfinished, and so, > no real OGo client exists in the totally free world. > If OOo's project takes off, and Evolution or Mozilla gets open/complete > OGo implementations, then, and only then, can OGo be considered a full > product. So are you suggesting that Red Hat take one direction because it is the only direction feasible (in your view) at the moment? Even when that direction will require changing the standard bundled ftp server, changing the standard bundled imap server, and forsaking every mail client currently included in the distribution in the process? I've got to disagree that a plugin for the Evolution / Kolab is more logical than making Evolution 'just work' with OGo. It's much more logical to make Evolution work with the established standards that OGo implements than have some weird plugin required to make it work with Kolab. Why the hell should we be required to *need* a plugin to make a FREE SOFTWARE mail client work with a FREE SOFTWARE collaboration suite? That makes no sense when a standards based Freedomware collaboration suite is available and all that remains is modifying Freedomware clients to work with those established standards. Then you get the bonus that those clients will also work with other *standards based* collaboration suites out there (current or future) without the need to write some plugin to connect each client / server combination. As has been stated in this thread, the bastardized ftp/imap calendar implementation is unlikely to be implemented by other Freedomware (thanks for the better terms, Bryan) in the near, or even distant future. The standards based calendaring features used in OpenGroupware, however, ARE likely to implemented by other email/collaboration clients since they are standard. If you haven't figured it out yet, Red Hat rarely, except in a few rare, relatively non-disruptive cases, takes a path that it going to make changes harder later down the road just to get something out the door. Personally, I like that about the company, and hope it never changes with respect to that quality. It's refreshing in the just-get-it-out-the-door mentality of most software companies today. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets
