[Kroupware] Re: client compatibility

[Kervin L. Pierre]

Bo Thorsen wrote:
>>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.
> 
> 

That's exactly our goal as well.  Different approaches I guess.

We're not re-implementing exchange.  The initial plan is to store all 
exchange calendar properties as-is in the IMAP server.  Future goal is 
to translate those for interoperability with IETF protocols based 
clients.  A bunch of the calendar properties are floating on the web 
here-and-there, so that's a start.

Outlook was written in a way that makes it possible to function without 
exchange, not an easy task, but possible do to the MAPI layer.

Working at the MAPI layer of the client ensures that you don't have to 
modify your server whenever MS changes an RPC call, etc.

In the end I think it's a harder fight tricking outlook into thinking 
that it's speaking to an exchange server or something similar, than it 
is to provide alternate default MAPI service providers for the outlook 
client.

--Kervin