Hello Henry, Thanks for the advice. I think it would be wise for us to take it, especially with the samples now being open-sourced.
I still would like to sync the PST store with a C# provider if that can work. The problem isn't technical, it's just that there aren't too many C++ application developers ( not counting embedded ) out there compared to .Net developers. The more code we have in .Net the better chance we have in attracting new developers. Hence the MAPI/.Net bridge. Best regards, Kervin -----Original Message----- From: Henry Gusakovsky [mailto:h.ghusakov...@gmail.com] Sent: Wednesday, July 22, 2009 2:49 PM To: g...@novadsp.com Cc: Dr. Net! - Eugen Rieck; otlkcon-devel@lists.sourceforge.net; Kervin Pierre Subject: Re: [otlkcon-devel] C# / COM+ - RE: Status? As far as I know MAPI is implemented _only_ for Windows and _only_ by MS. So guys I would seriously encourage you using Wrapped PST architecture for this project. It is not late so far. Just imagine that providers is loaded in the several profiles. By several processes. And event one process can create several instances. And all of them are working simultaniously. PST is well tested provider and using it as a base is more than start. -- Regards Henry On Wed, Jul 22, 2009 at 9:41 PM, g...@novadsp.com<g...@novadsp.com> wrote: > > > Dr. Net! - Eugen Rieck wrote: > > 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.) > > Yes IMHO this is absolutely the right way to do things. > > 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. > > Microsoft C++ is your friend here :) But there is no reason why the code > should not be as portable as possible. Is there MinGW MAPI support? > > Jerry. > > ------------------------------------------------------------------------------ > > _______________________________________________ > otlkcon-devel mailing list > otlkcon-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/otlkcon-devel > > ------------------------------------------------------------------------------ _______________________________________________ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
