client compatibility (was: Re: [kroupware] About mozilla calendar ...)
Lutz Badenheuer
kroupware@mail.kde.org
Tue, 21 Jan 2003 02:06:38 +0100
Hi Henning,
Am Montag, 20. Januar 2003 17:08 schrieb Henning Holtschneider:
> My personal opinion: if this project wants to get further than all
> the other half-finished groupware projects, people must not ask
> "why is my favorite client XY not supported" because there is not
> even *one* single finished client on *one* at all. Apart from that,
> there is no need to support more than one client per platform
> because it just makes the end-user and developer support more
> difficult.
I'm not sure whether it is a good idea to support each client app in
the universe. Think of the different solutions that you can find at
this time: the two who actually share the market, Outlook and Notes,
both rely on a proprietary model where client and server are shipped
by the same company. This does not seem to be a model that could be
found acceptable for an open-source project like this one.
Then, I've heard of solutions like iOffice (widely related), SuSE's
Groupware Server, HP (I think now it's Samsung) OpenMail and similar
approaches, like the first tests with a calendaring addon in the
world's fastest webmail app, sqwebmail, or more- or phpgroupware or
<you_name_it>. All those do not really show up big market shares, but
otherwise all them show up with many similarities: none of those
projects develops, ships and / or supports a client, none of those
can provide the full functionality of modern groupware apps.
This project is different, for it does not only provide a server --
Kolab -- but also a client, consisting of code from a bunch of apps
that are known to be working very well. KMail is state-of-the-art, to
say it simple, and KOrganizer, Kab and the other involved programs
belong to the fastest and most stable ones in KDE. :-)
So, in the end, you may guess my own opinion: I think that it will be
better to implement one client-server solution that will be ready for
productive tasks, and maybe then port the client to the Windows and
MacOS platforms. Here on the list there was someone who was working
on a port for KMail to Windows, using Cygwin, but since his posting
I've not heard about that project any more. :-(
At this time, and I am thinking of some sort of integration between
the projects, I see good chances to include KNode and some netnews
server into client and server, and I am thinking of ways to include
Perl-Qt into this project. I my very own opinion, netnews can provide
sophisticated enhancemants to corporate communication, and Perl-Qt
may provide a solution that makes it easy to implement individual
apps and workflow-specific solutions in a corporate environment.
> 1. Windows client
> -----------------
>
> As Andreas Jellinghaus pointed out back in September, the Bynari
> InsightConnector - which is the reference interface to the server
> on the Windows platform - stores the data on the server in a
> proprietary format which can only be read by InsightConnector. So,
> if you start off under Windows and then wish to switch your client
> platform to Linux, you cannot transfer any other data than your
> emails.
I do not think anyone in this list will be angry at you if you are
able to provide an open-source standard solution to connect Outlook
and Kolab without the need of InsightConnector.
> 2. Web-based client
> -------------------
Maybe sqwebmail with its beginning calendaring support can be a good
to start with.
Best wishes,
Lutz
--
Und nächste Woche lernen wir, wie man mit nur einer Frikadelle im
Kopf den nächsten Golfkrieg anzettelt. (http://onkelfisch.de/)
Lutz Badenheuer | IT--Consulting, Development, Networksolutions
luke@the-web-ac.com | C/C++, OO-Perl, sh | Linux, SCO UNIX, Solaris