I don't see the value in reverse-engineering Exchange's proprietary protocol when MAPI is such a full-featured and flexible API.from a service provider pov, there are a lot of advantages with a server side implementation.
The most important has been well-explained by Charles:
<quote>
A connector requires software to be deployed/maintained on each workstation and that is an expensive (time/money wise) process. I was an admin at a company with ~100 users and developed a custom software deployment system for our network. Using SMS was out of the question because of the expense. And we are still on an Exchange 5.5/NT4 architecture so even if SMS was available the expense of moving to Active Directory and Exchange 2000 or later is a show stopper
</quote>
and Charles is talking of just 100 users, while we currently have millions.
Please don't make me wrong, I'm not boasting or whatever: it's just that pros and cons may have a very different feeling in different contexts.
Still, as I already said, I think that the Outlook connector is the best compromise right now.
MAPI is _so_ flexible that it allows Outlook to include proprietary and undocumented properties; the view descriptor format comes to mind immediately. I've spent many hours changing views and poring over the changes to the format.I've just begun studying "Inside MAPI" (thanks Thomas) and I've got the feeling that my studies will last for a long time :-(
Luca
------------------------------------------------------- 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
