-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think this actually went to the list. Sorry if it did and this results in a duplicate response.
Regards, Jason Nocks - ---------------------------- Original Message ---------------------------- Subject: Re: [otlkcon-devel] undocumented MAPI in Outlook From: [EMAIL PROTECTED] Date: Tue, January 25, 2005 6:11 pm - -------------------------------------------------------------------------- - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [EMAIL PROTECTED] wrote: >> Implementing *all* of the MAPI >> interfaces for every MAPI object you want to implement would simply be maddening. Reverse-engineering which MAPI interfaces Outlook is going to use is almost, but not quite, as madenning. > > Jason, > this last sentence is quite scary :-) Sorry about that. Just don't want to paint an overly optimistic view. The road ahead is a bit long and arduous. Fortunately, there seem to be a few key ingredients starting to come together (more than 1 or 2 people and possibly some people with some time to dig into some of the more time consuming elements). > It's _surely_ too early for me to think of it: I would better go on studying and practicing MAPI. Not necessarily. Ideas are always welcome (speaking for myself at least). They are free and always worth at least that much. > So pardon me if I dare to give a suggestion: what about a "MAPI sniffer"? A piece of software that presents itself as a MAPI provider and just forwards Outlook requests to the Exchange MAPI provider and passes back the answers, logging all the traffic. We had exactly the same thought when we started working on a message store about a year and a half ago. This could definitely be done either "on the wire" or at the MAPI API level, like a proxy. We haven't done either of these. Even stubbing the entire MAPI API and having it wrap another message service seems like still a lot of work. It turns out that there's a fairly easy way to get much of the information you need. There are a number of MAPI message store viewers available, commercial and non-commercial, with and without source. MAPI is all about MAPI properties. MAPI objects are essentially just one or more MAPI properties with some functions to get or modify those MAPI properties. And MAPI properties are primarily available through the message store. In fact, I would call Outlook basically a "message store viewer". The main exception is address books, but they were moved into the message store when the "Contacts" folder appeared. So, a message store viewer (other than Outlook) lets you view *most* of the information you need, in a more controlled fashion. The biggest remaining problem is figuring out what the MAPI properties actually mean. Some of the MAPI properties are documented. Many of the *interesting* ones are not. The trick is making sense out of the 160 MAPI properties Outlook requests when it wants to display one MAPI object. Guess how many of the 160 MAPI properties are documented... For added confusion, a number of the properties are really the same. Plus, things get complicated due to Outlook trying to be smart, the way named properties work, etc. I don't want to dump too much low-level technical details in this particular email, just trying to give you an idea of what problems are faced. Also, I don't remember all of the details in exact detail off the top of my head. MAPI sometimes gets a bit more complicated down at the nitty-gritty detailed level. Reverse engineering Outlook's expectations isn't really difficult work, just incredibly time consuming. So, for those doing it in their spare time, well, there's just not tons of time to spare. Pardon the pun. There are some websites with some very helpful documentation about some of the undocumented properties, but much of what we found we have to do is trial and error, observe and make educated guesses, spray and pray, etc. Perhaps just documenting these MAPI properties would be an area where you could get a better understanding of how MAPI works while contributing some time if you have it. I'd be happy to share the properties I'm aware of to get the list started if this idea seems worthwhile. I would think that the same MAPI properties would also be transmitted "over the wire" for anyone working on the "over the wire" exchange replacement project. > You could see the properties Outlook requests and try to clue from the answers what is their semantics. Right, you can also just log what Outlook is trying to do to your service, do the same thing to exchange, observe what exchange does and try to mimic it. This is what we were doing. It works, but takes a lot of time. We also started working on writing automated validation tests for the message store we were working on. Basically, using a tool that would parse text files, reading expected MAPI properties and comparing them to actual MAPI properties in the message store. We called this a "Mapi Property Inspector". We thought this might help by allowing inspection of a "working" message store, putting those properties into text files for validation, then implementing the code to get the tests to pass. I could go on... I haven't looked into the SapiMapi subproject too much, but it looks like it is basically intended for similar purposes. > Maybe you already did such a thing... I just had to share this to you :-) Thanks, we've done similar things to what you are recommending. I've done my best to describe the approach we were using at SourceXtreme much of last year. > Luca Thanks for the thoughts. They make perfect sense. It might be worth pursuing a full-fledged MAPI sniffer. I'll happily leave that thought open for discussion. The above is not meant to be the be-all end-all final word here, just my thoughts and opinions. I'm certainly open to discussing the views and opinions held by others. Cheers, Jason Nocks - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9tIz3CryLfCgqRkRAt0QAJ4hz5rktBLw5xRwvM2yj6t7sYNMBgCfUjdi zei9QYCCKQDMqr1kW3JXQ3s= =RLzA - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB9tLP3CryLfCgqRkRAvmmAJ9rez4dCJhXWyp1wMMN6wVjyLlgiwCfeFoN 9SVbsiEf9P/h9gciK98nArc= =GDEK -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
