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
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
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
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:
