[Kroupware] Re: client compatibility

Chris Kaminski kroupware@mail.kde.org
Mon, 20 Jan 2003 12:15:31 -0800 (PST)


> I'm working on the MAPI Message Store Provider.  Goal of having an
> alpha 
> version of that code by halfway through February.  Hopefully this
> date 
> won't slip, it's a lot of code, but I've been giving it a much of my 
> time as well.  So we'll see.

It's that damn IMAPIProp interface.  :-) Such a simple little thing,
but it underpins everything else you've got to do!

> The MAPI Message Store Provider is suppose to be the largest MAPI 
> service provider needed.  Our goal is to work on the MAPI Transport 
> Provider next.  Another developer has been looking into it, but he 
> hasn't announced he's exact plans as yet.
 
I spent the weekend writing the MAPI COM stubs, and implementing
IMAPIProp (All service providers need to implement it at some level). 
I've got a two-level IMAPIProp interface, one class MAPIProp that has
all the same function signatures as IMAPIProp (except the IUnknown
bits), and the others are embedded in the normal COM stubs
(IXPProvider, IXPLogon, IMAPIStatus, etc).  This way I can reuse the
IMAPIProp bits without having to complicate the implementation in each
class.  

class IMAPIStatus 
private: 
   MAPIProp props; 

public: 
   //iunknown funcs 
   //IMAPIProp bits 
   //IMAPIStatus bits 
}; 

Last time I implemented a service provider, this mechanism sure helped
me save a lot of time, since IMAPIContainer, IMAPIItem and a few others
all have IMAPIProp interfaces.  

Let me know if you want my code bits (I'm working on a bunch of support
code (sockets, mutexes, guards, atomicop reference counters, etc)) as
well as unit tests for them.  Should have something and tests by the
weekend. 

> My goal is to first decouple outlook from exchange, just as Lotus, 
> Oracle, Bynari has done.  In fact in the exact same fashion, by 
> providing an alternate MAPI Message Store and Transport Provider.
> Longer term goals include translating outlook calendar properties to 
> IETF protocol data eg. xCal/IMAP, and/or CAP.  But that's after the 
> simpliest case of storing MAPI properties as-is as been stablizied.

A laudable goal, and one I concur with.  Either way, I've got some
shared code you may or may not want to use, stuff that's easier to
start sharing now rather than the MAPI COM bits.



=====
Chris Kaminski
 "I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain."
---Frank Herbert, Dune - Bene Gesserit Litany Against Fear

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com