client compatibility (was: Re: [kroupware] About mozilla calendar ...)

[Bo Thorsen]

On Monday 20 January 2003 17:08, Henning Holtschneider wrote:
> Am Mon, 2003-01-20 um 14.17 schrieb Manuel Hoppe:
> > So finally, is someone interested to found a project or join the
> > existing calendar team and develop a compatible client?
>
> 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.
>
> Now the technical side ;-) I think there are two areas where work has
> to be done in parallel to the *nix/KDE client or after that client has
> reached a production state.
>
> 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.

Why do you say this? We have been pretty succesful in decoding these. At=20
least appointments we can read just fine in the client.

And having the different implementations of the client use the same file=20
format is only interesting when you want to switch between them. The=20
kroupware project tried to do this and so far we have failed. All=20
communication between the different client types work fine.

> I do not like the idea of yet another client. Programming and
> maintaining an email client is a huge task and people won't like it
> anyway because is does not look familiar. I'm not thinking of geeks,
> developers or early adopters - I'm thinking of normal users who know
> how to use Word and Excel. If you want the Kolab server to be
> successful in a business environment, the Windows client has to be
> Outlook.
>
> The first approach would be a MAPI provider which enables Outlook to
> store its information on a server instead of the local .pst storage.
>
> Programming a MAPI provider is no easy task, but Kervin L. Pierre has
> started a project on Sourceforge (http://otlkcon.sourceforge.net/) in
> November. There has been no (visible) progress since then but
> considering Kervin's message to this list, he won't start working on it
> until about now ;-)

Why on earth do you want to reimplement Exchange with using the=20
proprietary fileformats we're all trying to get away from?

Your proposal here shows that you're in the wrong area. The whole concept=20
of the kolab server is orthogonal to what you want. We're focusing on=20
open standards, writing a client that supports them and getting Outlook=20
to work with it too.

> 2. Web-based client
> -------------------
>
> If the clients on the two major supported operating systems share the
> same data format, we can think about a web client. It doesn't have to
> be look-alike like Outlook Web Access but the user should be able to
> view all the pieces of information created with the KDE/Windows client.
>
> I think this part is fairly easy (i.e. one could use a modified version
> of an existing IMAP client like Squirrelmail) but it requires that the
> platform-specific clients use the same data format.

Yeah, right. Writing a normal client is a daunting task. Writing a web=20
based one is *not* going to be easier. And remember that we had a full=20
calendar program and an IMAP capable email reader to start off on.

Anyway, the whole concept you describe here is not what we intend to=20
provide. We will not abandon the concept of completely free standards.=20
The only exception to this rule is what we must do to make Outlook work=20
with it.

Bo.

P.S. Again I felt the need for some ranting. It is pretty annoying to be=20
part of a project when many of the mails send to the list lately are all=20
about why we should fundamentally do something different. So I'd like=20
future posters to this mailing list to actually *read* the concept papers=20
on www.kroupware.org and understand that the general concept is not going=20
to change. We are obviously happy with discussing implementation details,=20
but hearing someone elses thoughts on how we should do most things=20
different gets tiresome. If you want to say that we're wrong, do it with=20
code. We're bugfixing away from actually providing a working=20
implementation, so until I see something a little more tangible than=20
thoughts, I'll stay with the current direction.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark