You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(16) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
(5) |
Sep
(5) |
Oct
(10) |
Nov
|
Dec
(27) |
2004 |
Jan
(28) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(9) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2005 |
Jan
(48) |
Feb
(21) |
Mar
(3) |
Apr
(2) |
May
(7) |
Jun
(9) |
Jul
(7) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
(14) |
Dec
(7) |
2006 |
Jan
(35) |
Feb
(24) |
Mar
(10) |
Apr
(7) |
May
(5) |
Jun
(2) |
Jul
|
Aug
|
Sep
(10) |
Oct
(8) |
Nov
(7) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(3) |
Dec
(15) |
2008 |
Jan
|
Feb
(6) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(4) |
Jul
(3) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(3) |
2009 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(19) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <con...@mi...> - 2010-05-12 07:10:31
|
con...@mi... |
From: Scott P. <sco...@gm...> - 2010-01-15 00:58:17
|
I've been trying to get OpenConnector to work with a custom CalDAV implementation but have run into many issues and am currently stuck. First off, I configured the account's Home and Principal URIs to point it to one of our development boxes, clicked save and then browse, then tools->connect. I see the various OPTIONS & PROPFIND requests come across on the backend and the correct XML is being returned. The available calendar for the user specified then appears in the list - everything looks good so far. But immediately after the calendar shows in the list, another PROPFIND (depth=1) request is issued to the Home URI... however it is an empty request (well, a single space character). Our server interprets this as an invalid request and throws back a 500 error, which is displayed via the configuration tab as an unhandled exception. first question is whether this empty request is a bug that can be ignored or a byproduct of a bad configuration/installation on my end? I've tried to just ignore the request on our end, but when I do that, the OpenConnector client complains about an invalid response. Secondly, when I click to continue on the error dialog and check the checkbox next to the name of the calendar returned before the error, then click save and ok to complete the account configuration, everything looks ok. I see the calendar appear under My Calendars, and no errors are reported. However, no events are displayed in the calendar (despite the fact that they were returned to the client prior to the error). Similarly, new events created in Outlook are never synced - no PUT requests are made. Is this the byproduct of the previous error not being handled properly or does something else need to be set? Like I said, our CalDAV implementation is custom and by no means perfect - but it does work with Apple's iCal on OSX and iPhone, as well as Mozilla Thunderbird/Lightning on multiple OSs. We're trying to find a solution for our Outlook users and were hoping that OpenConnector would do the job for us. Any advice or help would be greatly appreciated! - Scott |
From: Mike M. <mik...@gm...> - 2009-08-28 16:19:43
|
As far as I know, the Open Connector does not currently work with iCal server. Hopefully, others can weigh in with more details. Mike On Fri, Aug 28, 2009 at 2:55 AM, Sergei kostenko < s.k...@it...> wrote: > Hello. > > > > We has Mac Server that has CalServer running for some users. > > > > After installation of Open Connector and creating Cal account in outlook > and setting up all user name/password/URL/And Principal URL I’m trying to > browse for calendar. > > > > And getting one error that says (401)Unauthorized > > > > I’m sure that I have user name and password typed correctly, I’m using full > name not alias, all URL is correct. Can u advice any way to resolve this? > > > > In advance ty. And sorry for my English. > > Sergij Kostenko > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > otlkcon-devel mailing list > otl...@li... > https://lists.sourceforge.net/lists/listinfo/otlkcon-devel > > |
From: Sergei k. <s.k...@it...> - 2009-08-28 10:36:03
|
Hello. We has Mac Server that has CalServer running for some users. After installation of Open Connector and creating Cal account in outlook and setting up all user name/password/URL/And Principal URL I'm trying to browse for calendar. And getting one error that says (401)Unauthorized I'm sure that I have user name and password typed correctly, I'm using full name not alias, all URL is correct. Can u advice any way to resolve this? In advance ty. And sorry for my English. Sergij Kostenko |
From: Steve W. <sw...@cr...> - 2009-07-24 13:12:43
|
Might also find some useful example code in the ClamWin source on sourceforge. Open source virus scanner (C++/python) with an outlook addin à http://www.clamwin.com/content/view/178/27/ From: Kervin Pierre [mailto:ke...@ad...] Sent: Wednesday, July 22, 2009 11:10 PM To: g4...@no... Cc: otl...@li... Subject: [otlkcon-devel] Big Changes - RE: development environment I took some time off to work on Open Connector today considering what weve spoke about. The connector source tree is now Microsoft Public License. This is an OSI approved license and it helps us utilize example code. Ive made the change on the Sourceforge project, and will update all documentation as we move along. The second make change is that Ive started a new code branch for the merging of our old providers with the Microsoft supplied code. The new providers will use the new Wrapped PST architecture. As time permits I will work on 1. Merging all CalDAV functionality into the new providers. 2. Merge installer and configuration GUIs into the new provider 3. Creating that .Net bridge to allow more development to be done in C# Anyone feeling like helping would be welcomed. Best regards, Kervin From: g4...@no... [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 7:17 PM To: Kervin Pierre Cc: otl...@li... Subject: Re: development environment - RE: [otlkcon-devel] 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 hadnt 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. Ill look into this further. Best regards, Kervin From: g4...@no... [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 2:32 PM To: Kervin Pierre Cc: otl...@li... Subject: Re: development environment - RE: [otlkcon-devel] Status? K, seen these? http://www.codeplex.com/OutlookMAPISamples Kervin Pierre wrote: You wont need Exchange, so that should help simplify the environment. You wont 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 wont 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 isnt 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_IP rop.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 youd like. I will try to clarify things as best as I can. Best regards, Kervin |
From: Kervin P. <ke...@ad...> - 2009-07-23 04:10:12
|
I took some time off to work on Open Connector today considering what we've spoke about. The connector source tree is now Microsoft Public License. This is an OSI approved license and it helps us utilize example code. I've made the change on the Sourceforge project, and will update all documentation as we move along. The second make change is that I've started a new code branch for the merging of our old providers with the Microsoft supplied code. The new providers will use the new Wrapped PST architecture. As time permits I will work on... 1. Merging all CalDAV functionality into the new providers. 2. Merge installer and configuration GUIs into the new provider 3. Creating that .Net bridge to allow more development to be done in C# Anyone feeling like helping would be welcomed. Best regards, Kervin From: g4...@no... [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 7:17 PM To: Kervin Pierre Cc: otl...@li... Subject: Re: development environment - RE: [otlkcon-devel] 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: g4...@no...<mailto:g4...@no...> [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 2:32 PM To: Kervin Pierre Cc: otl...@li...<mailto:otl...@li...> 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 |
From: <g4...@no...> - 2009-07-22 23:18:20
|
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:* g4...@no... [mailto:g4...@no...] > *Sent:* Wednesday, July 22, 2009 2:32 PM > *To:* Kervin Pierre > *Cc:* otl...@li... > *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 > > > |
From: Kervin P. <ke...@ad...> - 2009-07-22 22:26:22
|
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.g...@gm...] Sent: Wednesday, July 22, 2009 2:49 PM To: g4...@no... Cc: Dr. Net! - Eugen Rieck; otl...@li...; 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, g4...@no...<g4...@no...> 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 > otl...@li... > https://lists.sourceforge.net/lists/listinfo/otlkcon-devel > > |
From: <g4...@no...> - 2009-07-22 21:33:50
|
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 > > |
From: Kervin P. <ke...@ad...> - 2009-07-22 21:13:38
|
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: g4...@no... [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 2:32 PM To: Kervin Pierre Cc: otl...@li... 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 |
From: Kervin P. <ke...@ad...> - 2009-07-22 20:12:36
|
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...@dr...] Sent: Wednesday, July 22, 2009 2:28 PM To: Kervin Pierre Cc: otl...@li... 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 |
From: Henry G. <h.g...@gm...> - 2009-07-22 19:11:31
|
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, g4...@no...<g4...@no...> 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 > otl...@li... > https://lists.sourceforge.net/lists/listinfo/otlkcon-devel > > |
From: <g4...@no...> - 2009-07-22 18:46:09
|
ditto this: http://mfcmapi.codeplex.com/ I think a quick sketch of the component parts and their links would be a good resource to have. 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 > > |
From: <g4...@no...> - 2009-07-22 18:42:48
|
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. |
From: Dr. N. - E. R. <eu...@dr...> - 2009-07-22 18:28:08
|
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 |
From: Kervin P. <ke...@ad...> - 2009-07-22 17:22:21
|
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 From: g4...@no... [mailto:g4...@no...] Sent: Wednesday, July 22, 2009 7:09 AM To: Kervin Pierre Cc: otl...@li... Subject: Re: [otlkcon-devel] Status? Hello Kervin Over the next few months I could put some real effort into things. I'm still in the process of establishing what Scalix can do, for example. Over the two weeks or so, practically zero. got a wedding and a hundredth birthday. neither of which are mine but involve large & complex gatherings :) I propose: 1. Be able to build the current OC source snap. I pulled trunk using SVN. 2. Get the connector running in parallel with the Scalix binary - a Linux box is possibly easier to use for inspecting packets. I also have Ex03 running here on W2003. 3. Asking questions. So: What role does the current data layer play in OC? Please point me to any relevant URLs for docs I can read in the interim. ATB Jerry Kervin Pierre wrote: Hello, This is great news. How much time do you believe you can put towards the project? The most important work needed at this time is the figuring out how Outlook loads and uses a shared calendar. Coincidently, this is why the Exchange MAPI SDK was pulled in. I don't think much or any of it is used except for the header files. Figuring that out would require really good IDA Pro skills; No or little programming. The libraries used are from the Exchange MAPI download. I think it's at http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en now, but I can't confirm on my current computer. I have Ex2kSdk.lib, Ex2KSdkD.lib and sadapi.lib in the ExchangeSDK\Lib folder. Another thing that I would like to do is to move the data layer from C++/SQLite to C#/SQL Server Compact and use COM+ to communicate with Outlook. If we can get the performance we need for from that setup then that would help with getting new developers in the future. Best regards, Kervin From: g4...@no...<mailto:g4...@no...> [mailto:g4...@no...] Sent: Tuesday, July 21, 2009 5:17 PM To: Kervin Pierre Cc: otl...@li...<mailto:otl...@li...> Subject: Re: [otlkcon-devel] Status? Hello Kervin I can actively participate in development - I'm trying to establish what OC needs to get built. Which Exchange SDK are you using for the current release? Although the calendar aspect is good I'm most keen to get shared tasks up & running. Sadly cannot help with funding - indeed could use some myself :) When I get Zimbra configured I will get a chance to test their connector - right now it's an MX mess :\ Any info gratefully received G. Kervin Pierre wrote: Hello, I am unable to put in anytime into the project at this time, and no one has stepped in to continue or fund development. So I would have to say the project is stalled until this situation changes. Open Connector is primarily a CalDAV connector. So I think your best bet would be to go with one of the commercial offerings out there like Zimbra Connector or ZideOne. Best regards, Kervin From: g4...@no...<mailto:g4...@no...> [mailto:g4...@no...] Sent: Monday, July 20, 2009 10:03 AM To: otl...@li...<mailto:otl...@li...> Subject: [otlkcon-devel] Status? I'm trying to establish the status of this project - Can anyone tell me which parts of the Exchange SDK are required to build the connector DLL? Has anyone had good results using the connector with Linux servers like Zimbra or Citadel? Thx++ G. |
From: Kervin P. <ke...@ad...> - 2009-07-22 16:56:25
|
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...@dr...] Sent: Wednesday, July 22, 2009 3:56 AM To: Kervin Pierre Cc: g4...@no...; otl...@li... 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 |
From: <g4...@no...> - 2009-07-22 11:10:31
|
Hello Kervin Over the next few months I could put some real effort into things. I'm still in the process of establishing what Scalix can do, for example. Over the two weeks or so, practically zero. got a wedding and a hundredth birthday. neither of which are mine but involve large & complex gatherings :) I propose: 1. Be able to build the current OC source snap. I pulled trunk using SVN. 2. Get the connector running in parallel with the Scalix binary - a Linux box is possibly easier to use for inspecting packets. I also have Ex03 running here on W2003. 3. Asking questions. So: What role does the current data layer play in OC? Please point me to any relevant URLs for docs I can read in the interim. ATB Jerry Kervin Pierre wrote: > > Hello, > > > > This is great news. How much time do you believe you can put towards > the project? > > > > The most important work needed at this time is the figuring out how > Outlook loads and uses a shared calendar. Coincidently, this is why > the Exchange MAPI SDK was pulled in. I don't think much or any of it > is used except for the header files. > > > > Figuring that out would require really good IDA Pro skills; No or > little programming. > > > > The libraries used are from the Exchange MAPI download. I think it's > at > http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en > <http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en> > now, but I can't confirm on my current computer. I have Ex2kSdk.lib, > Ex2KSdkD.lib and sadapi.lib in the ExchangeSDK\Lib folder. > > > > Another thing that I would like to do is to move the data layer from > C++/SQLite to C#/SQL Server Compact and use COM+ to communicate with > Outlook. If we can get the performance we need for from that setup > then that would help with getting new developers in the future. > > > > Best regards, > > Kervin > > > > > > > > *From:* g4...@no... [mailto:g4...@no...] > *Sent:* Tuesday, July 21, 2009 5:17 PM > *To:* Kervin Pierre > *Cc:* otl...@li... > *Subject:* Re: [otlkcon-devel] Status? > > > > Hello Kervin > > I can actively participate in development - I'm trying to establish > what OC needs to get built. Which Exchange SDK are you using for the > current release? Although the calendar aspect is good I'm most keen to > get shared tasks up & running. > > Sadly cannot help with funding - indeed could use some myself :) > > When I get Zimbra configured I will get a chance to test their > connector - right now it's an MX mess :\ > > Any info gratefully received > > G. > > Kervin Pierre wrote: > > Hello, > > > > I am unable to put in anytime into the project at this time, and no > one has stepped in to continue or fund development. So I would have > to say the project is stalled until this situation changes. > > > > Open Connector is primarily a CalDAV connector. So I think your best > bet would be to go with one of the commercial offerings out there like > Zimbra Connector or ZideOne. > > > > Best regards, > > Kervin > > > > > > *From:* g4...@no... <mailto:g4...@no...> [mailto:g4...@no...] > *Sent:* Monday, July 20, 2009 10:03 AM > *To:* otl...@li... > <mailto:otl...@li...> > *Subject:* [otlkcon-devel] Status? > > > > I'm trying to establish the status of this project - > > Can anyone tell me which parts of the Exchange SDK are required to > build the connector DLL? > Has anyone had good results using the connector with Linux servers > like Zimbra or Citadel? > > Thx++ > > G. > > |
From: Dr. N. - E. R. <eu...@dr...> - 2009-07-22 07:56:31
|
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 |
From: Kervin P. <ke...@ad...> - 2009-07-22 01:21:15
|
Hello, This is great news. How much time do you believe you can put towards the project? The most important work needed at this time is the figuring out how Outlook loads and uses a shared calendar. Coincidently, this is why the Exchange MAPI SDK was pulled in. I don't think much or any of it is used except for the header files. Figuring that out would require really good IDA Pro skills; No or little programming. The libraries used are from the Exchange MAPI download. I think it's at http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en now, but I can't confirm on my current computer. I have Ex2kSdk.lib, Ex2KSdkD.lib and sadapi.lib in the ExchangeSDK\Lib folder. Another thing that I would like to do is to move the data layer from C++/SQLite to C#/SQL Server Compact and use COM+ to communicate with Outlook. If we can get the performance we need for from that setup then that would help with getting new developers in the future. Best regards, Kervin From: g4...@no... [mailto:g4...@no...] Sent: Tuesday, July 21, 2009 5:17 PM To: Kervin Pierre Cc: otl...@li... Subject: Re: [otlkcon-devel] Status? Hello Kervin I can actively participate in development - I'm trying to establish what OC needs to get built. Which Exchange SDK are you using for the current release? Although the calendar aspect is good I'm most keen to get shared tasks up & running. Sadly cannot help with funding - indeed could use some myself :) When I get Zimbra configured I will get a chance to test their connector - right now it's an MX mess :\ Any info gratefully received G. Kervin Pierre wrote: Hello, I am unable to put in anytime into the project at this time, and no one has stepped in to continue or fund development. So I would have to say the project is stalled until this situation changes. Open Connector is primarily a CalDAV connector. So I think your best bet would be to go with one of the commercial offerings out there like Zimbra Connector or ZideOne. Best regards, Kervin From: g4...@no...<mailto:g4...@no...> [mailto:g4...@no...] Sent: Monday, July 20, 2009 10:03 AM To: otl...@li...<mailto:otl...@li...> Subject: [otlkcon-devel] Status? I'm trying to establish the status of this project - Can anyone tell me which parts of the Exchange SDK are required to build the connector DLL? Has anyone had good results using the connector with Linux servers like Zimbra or Citadel? Thx++ G. |
From: <g4...@no...> - 2009-07-21 21:18:28
|
Hello Kervin I can actively participate in development - I'm trying to establish what OC needs to get built. Which Exchange SDK are you using for the current release? Although the calendar aspect is good I'm most keen to get shared tasks up & running. Sadly cannot help with funding - indeed could use some myself :) When I get Zimbra configured I will get a chance to test their connector - right now it's an MX mess :\ Any info gratefully received G. Kervin Pierre wrote: > > Hello, > > > > I am unable to put in anytime into the project at this time, and no > one has stepped in to continue or fund development. So I would have > to say the project is stalled until this situation changes. > > > > Open Connector is primarily a CalDAV connector. So I think your best > bet would be to go with one of the commercial offerings out there like > Zimbra Connector or ZideOne. > > > > Best regards, > > Kervin > > > > > > *From:* g4...@no... [mailto:g4...@no...] > *Sent:* Monday, July 20, 2009 10:03 AM > *To:* otl...@li... > *Subject:* [otlkcon-devel] Status? > > > > I'm trying to establish the status of this project - > > Can anyone tell me which parts of the Exchange SDK are required to > build the connector DLL? > Has anyone had good results using the connector with Linux servers > like Zimbra or Citadel? > > Thx++ > > G. > |
From: Kervin P. <ke...@ad...> - 2009-07-21 20:43:38
|
Hello, I am unable to put in anytime into the project at this time, and no one has stepped in to continue or fund development. So I would have to say the project is stalled until this situation changes. Open Connector is primarily a CalDAV connector. So I think your best bet would be to go with one of the commercial offerings out there like Zimbra Connector or ZideOne. Best regards, Kervin From: g4...@no... [mailto:g4...@no...] Sent: Monday, July 20, 2009 10:03 AM To: otl...@li... Subject: [otlkcon-devel] Status? I'm trying to establish the status of this project - Can anyone tell me which parts of the Exchange SDK are required to build the connector DLL? Has anyone had good results using the connector with Linux servers like Zimbra or Citadel? Thx++ G. |
From: <g4...@no...> - 2009-07-20 14:34:14
|
I'm trying to establish the status of this project - Can anyone tell me which parts of the Exchange SDK are required to build the connector DLL? Has anyone had good results using the connector with Linux servers like Zimbra or Citadel? Thx++ G. |
From: Kervin P. <ke...@ad...> - 2009-03-04 19:04:48
|
Hello Martin, Help would be much appreciated at this point in time. Currently I don't have much free time to put into the connector and I don't have a funding source, so development has been at a stand-still. Especially we need someone with a lot of experience with C++/Outlook and some x86 reverse engineering experience. Best regards, Kervin -----Original Message----- From: Martin Leonard [mailto:mle...@su...] Sent: Tuesday, February 24, 2009 7:47 PM To: otl...@li... Subject: Re: [otlkcon-devel] iCal Server + Outlook 2007 Hi Randall, I had exactly the same problem. I was going to try and get a pcap trace of the messages but then moved onto something else. I will try and get my setup working again and post any findings. I agree that Calendar Server and Open Connector make a very compelling combination. I am going to talk to Kervin and see if there is anyway we can help. Martin Leonard Director of Software Engineering Sutus Inc ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ otlkcon-devel mailing list otl...@li... https://lists.sourceforge.net/lists/listinfo/otlkcon-devel |
From: Martin L. <mle...@su...> - 2009-02-25 01:03:04
|
Hi Randall, I had exactly the same problem. I was going to try and get a pcap trace of the messages but then moved onto something else. I will try and get my setup working again and post any findings. I agree that Calendar Server and Open Connector make a very compelling combination. I am going to talk to Kervin and see if there is anyway we can help. Martin Leonard Director of Software Engineering Sutus Inc |