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
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.comg...@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
Re: [otlkcon-devel] C# / COM+ - RE: Status?
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 -- ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
Re: [otlkcon-devel] development environment - RE: Status?
This is very interesting. I hadn't noticed that. These providers have been around in one form or the other for at least 10 years now, first distributed with the MAPI Provider book. We could never use them though because there was no explicit license attached to the source. But with their inclusion on Codeplex and explicit license we can now probably utilize those. I'll look into this further. Best regards, Kervin From: g...@novadsp.com [mailto:g...@novadsp.com] Sent: Wednesday, July 22, 2009 2:32 PM To: Kervin Pierre Cc: otlkcon-devel@lists.sourceforge.net Subject: Re: development environment - RE: [otlkcon-devel] Status? K, seen these? http://www.codeplex.com/OutlookMAPISamples Kervin Pierre wrote: You won't need Exchange, so that should help simplify the environment. You won't need to inspect packets either. You will need to inspect assembly. Are you familiar with MAPI internals at all? Or IDA Pro and Assembly Language? I really only ever used a CalDAV server for testing. We can use Bedework ( http://bedework.com/ ) for this. If you plan on working on migrating the datalayer to C#, then you won't need a server at all. All the testing can be done locally. If you plan to work on shared folders support then you will need IDA Pro and lots, and lots of patience :) Unfortunately, there isn't much documentation. But I will be happy to answer any questions you may have. The role of the datalayer is to save MAPI data. This is what saves appointments and messages to the disk. It is only used by a very small number of interfaces. Actually IMAPIProp (http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup ) and IMAPITable being the biggest consumers. Currently, it uses an SQLite database. We should move this to SQL Server Compact for better locking, application transaction model and more support for platform database abstraction features. Again, feel free to ask as many questions as you'd like. I will try to clarify things as best as I can. Best regards, Kervin -- ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
Re: [otlkcon-devel] development environment - RE: Status?
K, seen these? http://www.codeplex.com/OutlookMAPISamples Kervin Pierre wrote: You won't need Exchange, so that should help simplify the environment. You won't need to inspect packets either. You will need to inspect assembly. Are you familiar with MAPI internals at all? Or IDA Pro and Assembly Language? I really only ever used a CalDAV server for testing. We can use Bedework ( http://bedework.com/ ) for this. If you plan on working on migrating the datalayer to C#, then you won't need a server at all. All the testing can be done locally. If you plan to work on shared folders support then you will need IDA Pro and lots, and lots of patience J Unfortunately, there isn't much documentation. But I will be happy to answer any questions you may have. The role of the datalayer is to save MAPI data. This is what saves appointments and messages to the disk. It is only used by a very small number of interfaces. Actually IMAPIProp (http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup ) and IMAPITable being the biggest consumers. Currently, it uses an SQLite database. We should move this to SQL Server Compact for better locking, application transaction model and more support for platform database abstraction features. Again, feel free to ask as many questions as you'd like. I will try to clarify things as best as I can. Best regards, Kervin -- ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
Re: [otlkcon-devel] C# / COM+ - RE: Status?
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.comg...@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
Re: [otlkcon-devel] development environment - RE: Status?
Hello all, Further searching around the Unix/MAPI theme shows Evolution has covered a lot of ground. See here for their project status: http://www.go-evolution.org/MAPIProvider This matrix is interesting too: http://www.go-evolution.org/MAPIProvider/vsOWA Jerry. Kervin Pierre wrote: This is very interesting. I hadn't noticed that. These providers have been around in one form or the other for at least 10 years now, first distributed with the MAPI Provider book. We could never use them though because there was no explicit license attached to the source. But with their inclusion on Codeplex and explicit license we can now probably utilize those. I'll look into this further. Best regards, Kervin *From:* g...@novadsp.com [mailto:g...@novadsp.com] *Sent:* Wednesday, July 22, 2009 2:32 PM *To:* Kervin Pierre *Cc:* otlkcon-devel@lists.sourceforge.net *Subject:* Re: development environment - RE: [otlkcon-devel] Status? K, seen these? http://www.codeplex.com/OutlookMAPISamples Kervin Pierre wrote: You won't need Exchange, so that should help simplify the environment. You won't need to inspect packets either. You will need to inspect assembly. Are you familiar with MAPI internals at all? Or IDA Pro and Assembly Language? I really only ever used a CalDAV server for testing. We can use Bedework ( http://bedework.com/ ) for this. If you plan on working on migrating the datalayer to C#, then you won't need a server at all. All the testing can be done locally. If you plan to work on shared folders support then you will need IDA Pro and lots, and lots of patience J Unfortunately, there isn't much documentation. But I will be happy to answer any questions you may have. The role of the datalayer is to save MAPI data. This is what saves appointments and messages to the disk. It is only used by a very small number of interfaces. Actually IMAPIProp (http://otlkcon.svn.sourceforge.net/viewvc/otlkcon/trunk/otlkcon/opncon/O_IProp.cpp?view=markup ) and IMAPITable being the biggest consumers. Currently, it uses an SQLite database. We should move this to SQL Server Compact for better locking, application transaction model and more support for platform database abstraction features. Again, feel free to ask as many questions as you'd like. I will try to clarify things as best as I can. Best regards, Kervin -- ___ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
