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

[Guido Bockamp]

Hey Bo, hey list,

What should I say: I do believe I can somehow understand Henning meens 
and I really appreciate his
detailed aproach, *but* in the end you are right, Bo! Do not let 
yourself be distracted. You are doing
just fine and - to my mind - have the correct approach the the problem. 
Keep going!

Guido

PS.: Ever thought of maybe making seperate lists e.g. "technical", 
"strategic", "helpdesk"? What does the
list say to this?


Bo Thorsen wrote:

>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 
>least appointments we can read just fine in the client.
>
>And having the different implementations of the client use the same file 
>format is only interesting when you want to switch between them. The 
>kroupware project tried to do this and so far we have failed. All 
>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 
>proprietary fileformats we're all trying to get away from?
>
>Your proposal here shows that you're in the wrong area. The whole concept 
>of the kolab server is orthogonal to what you want. We're focusing on 
>open standards, writing a client that supports them and getting Outlook 
>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 
>based one is *not* going to be easier. And remember that we had a full 
>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 
>provide. We will not abandon the concept of completely free standards. 
>The only exception to this rule is what we must do to make Outlook work 
>with it.
>
>Bo.
>
>P.S. Again I felt the need for some ranting. It is pretty annoying to be 
>part of a project when many of the mails send to the list lately are all 
>about why we should fundamentally do something different. So I'd like 
>future posters to this mailing list to actually *read* the concept papers 
>on www.kroupware.org and understand that the general concept is not going 
>to change. We are obviously happy with discussing implementation details, 
>but hearing someone elses thoughts on how we should do most things 
>different gets tiresome. If you want to say that we're wrong, do it with 
>code. We're bugfixing away from actually providing a working 
>implementation, so until I see something a little more tangible than 
>thoughts, I'll stay with the current direction.
>
>  
>