I started working on this C# bridge a while back. In the solution, there's a C# project called "OpenConnector". This buildings the executable used to access the network amongst other things. This exe communicates to the MAPI plugin via a shared memory protocol. Almost all ( if not all ) CalDAV communication is done in this exe.
The problem currently is that I am using a course-grain locking/polling algorithm for synchronization between the C# executable and the MAPI plugin. It's really too slow for any meaningful volume of data. The MAPI API and the .Net CLR cannot be loaded in the same process space. So using regular C#/COM is out. But one solution I haven't tried as yet is COM+ and dllhost.exe. See... http://www.codeproject.com/KB/dotnet/complusnetpracticalapp01.aspx This _should_ provide the isolation between MAPI and .Net CLR that we need without the course-grain locking. We can then move the data layer into the C# project. Once the data and the network layers are in .Net we can work on making the MAPI plugin more and more of a stub connector between Outlook and our C# code. The problem is someone has to actually sit down and commit to doing this code :). It is a lot of work... Best regards, Kervin From: Dr. Net! - Eugen Rieck [mailto:eu...@drnet.at] Sent: Wednesday, July 22, 2009 3:56 AM To: Kervin Pierre Cc: g...@novadsp.com; otlkcon-devel@lists.sourceforge.net Subject: Re: [otlkcon-devel] Status? Kervin Pierre schrieb: Another thing that I would like to do is to move the data layer from C++/SQLite to C#/SQL Server Compact ... that would help with getting new developers in the future. You bet on this! If I get a really working sort of bridge between Outlook and a well-defined C# interface in my hands, I will 100% surely add the second step from this interface to whatever my customers use. Native Zarafa is first on my list - hell, just a MySQL database directly on a server would provide excellent opportunities! Sorry for not working on the first part - my C[++] skills are really bad. I implemented a Storage Provider in Pascal, but it never really worked well. Best regards, Eugen
------------------------------------------------------------------------------
_______________________________________________ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
