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