This sounds good. But the serialization/deserialization ends up being a lot of
work. MAPI is a large API, so even after reducing things as much as I can I
ended up with a large "vocabulary" for the protocol. Also not all the calls
are data access related, so the database could not be used as much.

With COM, ideally IDispatch does this for us.
The C++ stubs could be rewritten easily if the C# ( Mono or otherwise ) COM+
server was done. Something like
http://my.execpc.com/~gopalan/dotnet/complus/complus.net_accountmanager.html
that exposes IMAPIProp, IMAPIPropData, IMAPITable, and IMAPITableData
interfaces.
Does that sound interesting to you?
Best regards,
Kervin
From: Dr. Net! - Eugen Rieck [mailto:eu...@drnet.at]
Sent: Wednesday, July 22, 2009 2:28 PM
To: Kervin Pierre
Cc: otlkcon-devel@lists.sourceforge.net
Subject: Re: C# / COM+ - RE: [otlkcon-devel] Status?
Kervin Pierre schrieb:
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.
Maybe my old abandoned Pascal project is still of use for the structure:
I implemented only stubs, these just serialized the request and sent it to a
socket. On the other end there was a worker daemon unserializing the call,
doing the work, serializing the reply and sending it back.
The idea behind that (and this part worked OK) was, that the worker daemon
could run on the same machine (use either socket to localhost or named pipe) or
on the server (use real network socket). The worker daemon itself can do
different things: Go to the Database directly (e.g. Zarafa server or just a DB
instance - MSSQL or MySQL or whatever) or proxy to something else (Zarafa via
API, Scalix, CalDAV, etc.)
My (finally unsolvable) problem was, that there was no good way for memory
management - using the functions from the MAPI helper object was not really
working from Free Pascal 1.x, all workarounds and hacks ended in either extreme
memory leaks (Read: Never free any memory) or weird segfaults.
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.
Just to make that clear: In my model there can be (quite many) concurrent
requests from one instance of the MAPI plugin to the worker daemon, so the
locking is moved to the datastore level, as I figured a Database is quite good
in locking.
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.
Sorry again - I am an old fart and have never (really) learned C[++], I come
from the dark Pascal ages and skipped directly to Mono (.NET) and PHP.
Basically: If somebody (the two of you?) manage to get the C++ stubs running,
so that every call is just serialized in some documented way and passed on to a
socket, I am happy to provide the following layer (in C#).
I guess it's a smaller step from there to connectors for different groupware
servers.
HTH,
Eugen