104672 - [Trunk only] Trunk landing meta bug for simple MAPI

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect, P1)

Description

[Tiantian Kong]

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

Comment 1

[Tiantian Kong]

bug 102570, reference for this bug.

Comment 2

[Tiantian Kong]

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.

Comment 3

[Krishna Mohan]

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

Comment 4

[Krishna Mohan]

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.

Comment 5

[scottputterman]

reassigning to rdayal

Comment 6

[Srilatha Moturi]

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

Comment 7

[scottputterman]

this won't happen until 0.9.8

Comment 8

[Rajiv Dayal]

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.

Comment 9

[Alec Flett]

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)

Comment 10

[Rajiv Dayal]

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).

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

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?

Comment 12

[Alec Flett]

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

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 14

[Rajiv Dayal]

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.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 16

[Daniel Veditz [:dveditz]]

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.

Comment 17

[Alec Flett]

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)

Comment 18

[John Marmion]

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. 

Comment 19

[Rajiv Dayal]

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.

Comment 20

[Rajiv Dayal]

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

Comment 21

[John Marmion]

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.

Comment 22

[Trix Supremo]

verified on mozilla & netscape trunk 2002022703 builds