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
------------------------------------------------------------------------------
_______________________________________________
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
