|
On Tuesday 01 February 2005 01:18 pm, Luke Kenneth Casson Leighton wrote: > dear outlook connectors, > > i wrote last week to say that i'm doing an exchange 5.5 server which > basically means implementing a MAPI server. My understanding (in MAPI speak) is that Exchange acts like the server side of the MAPI transport provider. Exchange *also* implements a MAPI message store and address book (and...). Not having access to the source code behind Exchange, I'm basing this assumption on the fact that the MAPI API is also available for code running on the server and that you can access folders, etc. similarly to accessing the message store on the client side. No doubt there are some differences, of course. > i've since discovered a few things: > > 1) the MSRPC Nspi interface's data structures are > identical to those in mapidefs.h (according to > /usr/include/wine/windows/mapidefs.h) This seems to support the notion that the data between Outlook and Exchange is basically serialized MAPI properties. > 2) the otlkcon0/mstore/*.cpp code looks like a more "full" and > "complete" version of what i'm rather foolishly trying > to implement as hard-coded data structures in my > network-reverse-engineering efforts. There's still some distance to go to implement all of the MAPI interfaces (plus all of the methods Outlook expects to be supported in those interfaces). But Kervin (and others?) has done a great job getting an initial MAPI message store to load in Outlook. This is not a small feat. > therefore, i would envisage a situation where porting and tweaking > otklon's mstore code to a linux FreeDCE service behind an Nspi > and EMSMDB interface would result in well... a free software > exchange 5.5 server where you didn't have to plug in DLLs on > the client or the exchange server. We might be able to have the best of both worlds. Two projects with significant overlap and code reused between them. How does that sound? Some people might want to install a custom service in Outlook that communicates natively (and more optimally) with an existing groupware server. Others may just want to get rid of Exchange and would be happy with an Open Source MAPI server. Not having to install binaries on every Windows desktop will certainly appeal to many. Personally, I don't see the two projects as mutually exclusive. Actually, I seem them as having a great deal in common. I think the greatest unknown is "undocumented MAPI properties" that Outlook relies on. I think these need to be figured out whether you are talking directly to Outlook as a local message store DLL, or as an Exchange server. > how about it? > anyone interested? Yes! > l. Regards, Jason Nocks |
pgp37WMRYWkQ4.pgp
Description: PGP signature
