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
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
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 ) CalD
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
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 i
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
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
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
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
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 inc
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 A
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
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:
Th
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 docume
14 matches
Mail list logo
