To track the trunk landing of simple MAPI. I'll add depedency bug list once we start to work on trunk landing.

bug 102570, reference for this bug.

In progress. Krishna: rework on logon/logoff. Rajiv: bug 103785 Srilatha/Rajiv/Krishna: get r/sr stamp for trunk for their own bug that has been checked into branch.

The directory structure for simple MAPI is differing on the trunk from 0.9.4 branch. The new directory structure is as below : Old directory structure on trunk : --------------------------------- mozilla/mailnews/mapi/resources - no change (leave as is) mozilla/mailnews/mapi/old - no change (leave as is) if there are any other directories, they are just temporary to post a patch and there are no files in there. these directories can be deleted. Regarding makefile.win files : ---------------------------- source makefile.win files dominates and no need to copy from the destination folders New direcotry structure on trunk : ---------------------------------- 1) copy mozilla/mailnews/mapi/mapiDll from 0.9.4. branch as is in to mozilla/mailnews/mapi/ of the trunk. 2) copy mozilla/mailnews/mapi/mapihook/*.* from 0.9.4 branch as is into mozilla/mailnews/mapi/mapihook/src/ of the trunk and delete msgMapiSupport.cpp and msgMapiSupport.h files. Basically don't copy these two files. 3) copy mozilla/mailnews/mapi/registry/src/*.* from 0.9.4 branch as is into mozilla/mailnews/mapi/mapihook/src of the trunk and delete Registry.cpp and Registry.h. Basically don't copy these two files. 4) copy mozilla/mailnews/mapi/registry/public from 0.9.4 branch as is into mozilla/mailnews/mapi/mapihook/ directory of the trunk. 5) copy mozilla/mailnews/mapi/build from 0.9.4 branch as is into mozilla/mailnews/mapi/mapihook/ directory of the trunk

Steps 2 and 3 have been slightly modified to minimize the changes. Modified Step 2) msgMapiSupport.cpp and msgMapiSupport.h remains the same as 094. Modified Step 3) Registry.h and Registry.cpp remains the same. These above mentioned files are not deleted.

reassigning to rdayal

Before landing on the trunk these changes need to be made on the trunk. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&ro ot=/cvsroot&subdir=mozilla/mailnews/base/prefs/resources/content&command=DIFF_FR AMESET&root=/cvsroot&file=pref-mailnews.js&rev1=1.5.82.1&rev2=1.5.82.2 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&ro ot=/cvsroot&subdir=mozilla/mailnews/base/prefs/resources/content&command=DIFF_FR AMESET&root=/cvsroot&file=pref-mailnews.js&rev1=1.5.82.2&rev2=1.5.82.3 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&ro ot=/cvsroot&subdir=mozilla/mailnews/base/prefs/resources/content&command=DIFF_FR AMESET&root=/cvsroot&file=pref-mailnews.xul&rev1=1.50.2.1&rev2=1.50.2.2 http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&ro ot=/cvsroot&subdir=mozilla/mailnews/base/prefs/resources/content&command=DIFF_FR AMESET&root=/cvsroot&file=accountUtils.js&rev1=1.14.14.1&rev2=1.14.14.2

this won't happen until 0.9.8

It has been decided to land MAPI on the trunk and fix the commandline handler related bug(s) 56654/103785 after landing MAPI on the trunk. The repercussion of this is that if Mozilla is not already running it will display the Mozilla browser window when Mozilla is started for MAPI on a MAPI call being made by its client. However all the MAPI functionality would work fine besides this browser window showing up. This will enable MAPI support to be on the trunk and allow people to use it with the MAPI apps and thus go thru more thorough testing before 0.98. The MAPI trunk landing will be done using the MAPI_NEW_DIR_TRUNK branch which has been reviewed and super-reviewed as part of the bug # 106137.

ok, but as long as you don't go tweaking nsAppRunner.cpp to add mapi-specific code :) (like it is on the N6.2 branch)

Sure. All traces of MAPI code is already out of nsAppRunner since 0.97 and the plan is to use nsICmdLineHandler, which however would require enhancement to provide arbitrary processing (bug # 56654 / 108766).

The mapi\mapiDll and mapi\mapihook contain no Makefile.in files; these are needed if GNU make is used on Windows for building Mozilla (bug 58981). Will they be added?

Christian: MAPI is currently a windows-only feature, so no Makefile.in's are required (nor would the code even compile)

Alec, if GNU Make is used on Windows as described in bug 58981 and done by me, Makefile.in's are used on Windows.

MAPI has landed on trunk, so marking this as fixed. A separate bug should be filed for having Makefile.ins to use Gnu compiler on Windows. Also, MAPI support uses MS COM for IPC so for using the Gnu compiler u would need MS COM libs and Dlls which u would need to install separately. So not sure whether having these Makefile.ins for Gnu compilation make sense.

Only GNU Make is used, not the Gnu Compiler. The compiler is still MSVC, only nmake is replaced by gmake.

right, only nmake is changed for now, allowing people to start experimenting with switching compilers in the future. Borland's compiler, for instance, would come with all the correct libs.

right... not to mention that at some point you'll probably be able to use cygwin and the Microsoft Platform SDK to build mozilla..(that's a bit further out)

I have an observation to make following this landing into the trunk. I am not sure if this is the best place but here goes. Mozilla not only has the ability to import Outlook data into its Address Book but with the landing of bug #78931 some time ago, also has the ability to directly access/modify Outlook Address Book data. This latter access also opens up the possibility of Mozilla's Outlook AB as the basis for syncing with a variety of PDAs rather than Outlook itself. To support both import and direct Mozilla AB MAPI access of Outlook, then Outlook must be the default Mail Client in IE. Following this landing, Mozilla will always configure itself as the default mail client. Thus Importing and Direct Access to Outlook will always fail. Users will only be confronted with a choice when before they access the AB, they either update the registry directly or run IE and change the registry IE Default Mail Client value earlier updated by Mozilla. But that choice is honoured for this session only and will be overridden each time you run mozilla.

Mozilla will configure itself as the default mail client only when u start it the very first time, this happens because the default value for the pref which governs the default mail client setting is set as checked. Once the user changes the setting to FALSE by either unchecking the pref "Use Netscape/Mozilla Mail as the default mail application" in Edit/Preferences dialog box or by starting any other mail app, that pref value (un-checked) is saved and Mozilla will ask you if u want to set it as the default mail client when u start it again. The user can thus use the other app as the default mail client. I will file another bug for this to debate if we should set Mozilla as default mail client by default.

New bug filed (bug # 120134) as for comments # 18 & 19. New bug filed (bug # 120135) for comments # 11 & 14.

Thanks for response Rajiv. I missed the preferences option. I am happy to see Mozilla setting itself as the Default Mail Client. My query regarded how it could be changed. The behaviour I am seeing is that Mozilla sets itself EVERY time it runs regardless of the preference option. Or maybe because I am running in a development environment I am missing something? If so, I apologise.

verified on mozilla & netscape trunk 2002022703 builds