91702 - Enable simple MAPI support in mail

Status: VERIFIED FIXED

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

Description

[Tiantian Kong]

Simple MAPI is supported in NS4.x, but not in NS6.x. 

What is simple MAPI?   "Simple MAPI (Microsoft Messaging Application Program
Interface) is a set of 12 common API calls which allow an application to send,
address, and receive messages. MAPI support can be used to allow non-messaging
applications such as spreadsheets and word processors to perform messaging
operations." ( From NS 4.x spec )

NS4.x supports these 12 common API calls such that when applications make calls
to them, it utilizes messenger to perform the mail tasks. 

Why we need simple MAPI support in NS6.x:
(1) to ensure deployment from enterprise customers.
(2) to provide convenience for individual customers.

This bug is to track and organize the development effort to enable simple MAPI
support in NS6.x. 

( NOTE: Full MAPI will not be supported.)

Scot, Jussi, Tiantian, Srilatha, Krishna, and Rajiv had a meeting this
afternoon, 7/20. 

Krishna and Srilatha will do a prototype to investigate the scope of work. Once
we are clear about the scope of work, we'll have a development plan. We'll meet
again next Tuesday, 7/24.

Here's a initial to-do list from Krishan:

"1. Simple MAPI Interface implementation is tightly integrated with Netscape 4.x
code.  So, need to check out weather all those functions and data types still
exists in 6.x code.
2. Look out for changes in the Simple MAPI specification.
3. Provide Code for all the Simple events; With Shared memory as IPC Channel.
4. Need to check error logging.
5. Need to check Response codes.
6. Little bit of XUL is need to create the Hidden Window."

The following people will provide help and consulation.
Mail: David Bienvenu ( [e-mail] )
Compose window: Jean-Francois Ducarroz  ( [e-mail] )
address book: Candice Huang  ( [e-mail] )
XP toolkit: Daniel Matejka ( [e-mail] )

Comment 1

[scottputterman]

I think we should assign this to Krishna since he will be doin the work.

I'm changing the summary since this should work in all mozilla based mail
products, not just NS 6.x products.

Comment 2

[Tiantian Kong]

(1) Added nsEnterprise keyword.
(2) Per comments from Krishna and Srilatha, I talked to Mitch Faatz. There may
need to be changes for the installation script.
(3) Added in the cc list: eClient tech writer ( [e-mail] ) , CPD
tech writer, ( [e-mail] ) and UI designer ( [e-mail] ).
(4) Going to get eClient QA support from Hong.

Comment 3

[Tiantian Kong]

Copied email from Jonathan Granrose for future reference:

"I see both Warner and Time want Simple MAPI support as a high priority. 
Whatever MAPI support we do (simple or extended), my only request is that we
implement it fully and cleanly and fully document it.  Since I'm assuming we'll
need to include our own mapi DLLs to enable mail access to Netscape from
non-Netscape apps, the ability to install or remove those DLLs separately from
NS6 would be key as well.

The MAPI situation for 4.x was a full on nightmare, especially from a tech
support standpoint.  Anything we can do to keep that from repeating itself in
6.x would be a big win.

Thanks for listening,

-j "

Comment 4

[Rajiv Dayal]

Attachment: initial draft for analysis of N4 MAPI support and design approach for MAPI support in Mozilla/N6

Comment 5

[Håkan Waara]

Since this won't make it to Mozilla, it's just confusing to have it in bugzilla.

I think you should move this bug, as the last bug about MAPI (the bug about
implementing it) contributed to some confusion when it became known that it is a
Netscape-only feature.

Comment 6

[(not reading, please use [e-mail] instead)]

why wouldn't we want MAPI support in mozilla?

Comment 7

[(not reading, please use [e-mail] instead)]

hopefully, as much of this code as possible will live in the mozilla tree.

Comment 8

[David :Bienvenu]

Hakan, you lost me - why won't this be in mozilla? I believe Scott explicitly
said it would be in Mozilla.

Comment 9

[WD]

A few comments about Rajiv's draft:

The NS 4.x Simple MAPI dll is a bit flaky.   Especially in the handling of
messages with attachment and program stability when handling messages with no
MIME preamble.   I work for a company that has a product which pretty
extensively uses the Simple MAPI interface, and I've noticed these problems
first-hand with Netscape 4.x.    So I agree with the idea of starting from "scratch"
FWIW, you can see the SMAPI compliance of 4.x at the following URL:
http://developer.netscape.com/docs/manuals/communicator/mapisupp.htm

On a Win32 system, the file which handles MAPI is MAPI32.DLL and it's located in
the System folder.   On a system with IE5 or later, the MAPI32.DLL file is
"smart" and does not (and **should not**) need to be overwritten.   When a user
selects the default mail client in the control panel, all calls to MAPI32.DLL
get "forwarded" on to the actual client's MAPI dll as specified by the DLLPath
registry entry.     For example.

If a user selects "Mozilla" to be the default mail client in the control panel,
HKLM\Software\Clients\Mail\(Default) is set to "Mozilla"
When a simple MAPI call is placed, MAPI32.DLL (the Microsoft one) will take a
look at the registry value: HKLM\Software\Clients\Mail\Mozilla\DLLPath , which
may have a value of something like 
"C:\Program Files\Mozilla\program\mzmapi32.dll"

So even though the file MAPI32.DLL in the System folder is the
Microsoft-provided one, all of the Simple MAPI calls get transparently sent to
the DLL in the registry key above.  (mzmapi32.dll)   It's as if the MAPI32.DLL
in the system folder was the one provided by Mozilla.
This works nicely, because no overwriting of DLLs is required!   This avoids
(all?) of the problems listed in the last section of the proposal labeled
"Problems with using Netscape MAPI dll", such as not being to launch Outlook.

In cases where the system is an IE4 or earlier system, it's not as clean to set
up simple MAPI.   The DLLPath registry key is ignored and if a program is to be
the default Simple MAPI client, then it must replace the MAPI32.DLL file in the
system folder.     (backing it up).   When the program is uninstalled or
specified to not be the default mail client anymore, the original MAPI32.DLL
file is restored.    I'm not certain what exactly controls what is done "behind
the scenes" when the default mail client is changed in the Windows Control
panel, though.  When changing certain mail clients, it can involve an amount of
disk activity, so perhaps the program is replacing the MAPI32.DLL file as necessary.

In an IE4 or earlier system, it is possible to get in a situation where a
program is the default Mail client but not the default Simple MAPI client.  
(MAPI32.DLL is the non-smart Microsoft-provided one, but in the control panel
the default Mail Client is something else).   In this scenario, when a simple
MAPI call is made, whichever MAPI32.DLL is in the system folder determines which
application responds to it.

I guess this was a bit of a ramble, but hopefully somebody will find some of it
useful...

Comment 10

[Håkan Waara]

I thought this wouldn't be added as it was said in the other (recently fixed)
MAPI bugs that they had licensing issues or something, and that it would only go
to NS6.

Hopefully I was wrong.

Comment 11

[Mitch Green]

I would expect this to be in Mozilla, if not picked up in the Mozilla browser,
at least developed in the open source tree.  If anyone knows whether we need to
clear copyright issues to get any (are there any?) re-used lines of source from
the 4.X implementation introduced into Mozilla.org, please let me know asap. 
Or, if we need to develop in a "clean room", then we need to know that asap as well.

Comment 12

[Håkan Waara]

My personal opinion would be that we shouldn't (and possibly, can't) reuse 4.x
code in Mozilla.  This project is all about rewriting this from scratch.

Either way, we should probably contact [e-mail] regarding this issue.

CC brendan

Comment 13

[Jon Granrose]

I'd rather see us develop a new implementation and know how to fix the bugs that
we'll have, rather than starting with known bad code and trying to fix bugs we
couldn't find or fix in the 4.x implementation.

Comment 14

[David :Bienvenu]

I don't think this is really an issue - On the one hand, the client interfaces
are all completely different so the interesting parts are all going to need to
be rewritten. And on the other hand, if our 4.x MIME code has problems with
mal-formatted documents (I was not able to follow this link -
http://developer.netscape.com/docs/manuals/communicator/mapisupp.htm so I can't
tell what the actual problem was), then the mozilla MIME code probably has the
same problem. (And if anyone dares suggest that we rewrite the MIME code, then
they should feel free to go for it! :-) )

Comment 15

[scottputterman]

We ported a bunch of mail code from 4.x.  Of course, it had to be integrated
into the new world.  I don't see why this should be any different. I think we
should reuse what we can reuse and rewrite what we can't and try to get a good
implementation done as quickly as possible.  

Comment 16

[Brendan Eich [:brendan]]

hwaara: this project is not about rewriting everything from scratch, that's just
silly.  We use NSPR, JS, and other modules that were not rewritten (other than
incrementally, as owned, living codebases) from the "Classic" days.  What is the
problem you're trying to solve here, by cc'ing me?

If the MAPI code is crap, then by all means don't use it, but that's not an
assessment I can help make right now.

If the code is properly licensed, it can be considered by the relevant owners
and peers.  What is the license?

/be

Comment 17

[Rajiv Dayal]

Based on the analysis that we have done (please see the attached draft doc 
above) it seems like there would be very little that we will be able to reuse 
from the N4 code base for mapi support. The N4 code is well written however not 
too much can be beneficially used for our implementation. In fact reusing it 
might make our implementation for MAPI support in Mozilla more complex and the 
design not straight forward (please see topic "Approach for MAPI support in 
Mozilla" in the document attached above).

Comment 18

[Srilatha Moturi]

Here's the link to the Simple MAPI documentation.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mapi/html/_mapi
1book_functions_for_c_and_c_.asp
This documentation is viewable from IE. In communicator and mozilla it is 
displayed as page not found. But if you copy the link location for the API and 
paste it in the location bar and remove the space in it, then it will be 
displayed fine.

Comment 19

[Rajiv Dayal]

Our approach for providing MAPI support in Mozilla/Netscape 6.x was to not use 
any of N4 implementation of mapi32.dll. We had planned to re-design the 
mapi32.dll that will export and implement the Simple Mail APIs.  On being called 
the new implementation will first check whether mozilla is already running, if 
not it will invoke mozilla. It will then convert the data passed in as 
parameters to the Simple Mail APIs to mozilla data structures and then use XPCOM 
to call the mozilla\mailnews interfaces that provide the messaging 
functionality.

The above will result in the mapi32.dll being mapped and loaded into the process 
space of the calling application. The invoked mozilla will run as a separate 
process. Hence the XPCOM call from mapi32.dll to mozilla\mailnews interfaces 
will be an inter-process call (IPC).

However, XPCOM does not support interface calls across processes. Thus the 
mailnews dll implementing the called interface will be loaded into the calling 
process by XPCOM. This creates a new data segment and the calls to the mailnews 
interfaces do not use the data in the invoked mozilla process. 

The possible solutions to this problem are :

1. Use the existing mapi32.dll implementation in N4 and the same design. The 
existing mapi32.dll will use Windows Shared memory and SendMessage for IPC to 
Mozilla. Rewrite the N4 hook part to be part of Mozilla and use mozilla\mailnews 
interfaces (Please refer to draft analysis and design doc for N4 overall 
architecture) However, this will have a lot of Windows specific code.
2. Modify the mapi32.dll to use NSPR Shared Memory and NSPR pipes for IPC and 
re-implement the hook part that will use NSPR IPC and call the mozilla\mailnews 
interfaces.
3. Use DCOM to take care of the IPC details (this is Windows only feature). 
Export mozilla\mailnews for required messaging functionality and register 
mozilla executable as DCOM component. Write the mapi32.dll to call these 
mozilla\mailnews DCOM interfaces, DCOM will handle the call across process 
space.
4. Load all the required dlls of mozilla required to be loaded for 
mozilla\mailnews. We will need to figure out what all mozilla start up dlls 
needs to be loaded, in what order and in which way so that all initialization is 
done to access mailnews interfaces and functionality.

Comment 20

[timeless]

see also
bug 68702 [RFE] Implement inter-process communication (IPC) in Mozilla

Comment 21

[Tiantian Kong]

With the help from Doug Turner, David Bienvenu, Jean-Francois Ducarroz, Roger
Chickering, our team has made the decision to use the COM technology to handle
IPC on 8/6. An updated design doc will soon be attached to this bug.

Below is a to-do-list:

(1) MAPI32.dll
- exposing MAPI interface (make files)
- converting MAPI parameters data to be COM compliant
- using strings within MAPI32.dll, make them UNICODE.
- make decisions for instantiate Mozilla and UI.
- make decisions for the cleanup of Mozilla instances.

(2) Interfaces for simple MAPI in Mozilla mail news.
- defining COM compliant interface API
- data conversion from interface data to mailnews/Mozilla data struct.
- implement the API using mailnews interaces for logon, logoff, send mail, send
document

(3) installation & pref management.
- register MS COM component for MAPI support (by the installer team)
- change/modify registry setting for MAPI dll (by the installer team)


(4) integration, testing ( Hong will provide a dedicated QA on 8/13.)

(5) For the mailnews part: review by Jean-Francois, super review by David. 

(6) For the COM part: super review by Doug.

Team decided that Krishna and Srilatha will implement the flow from mapi dll to
Mozilla mailnews for the logon feature during the next 7 days. Estimated
delivery date to QA is 8/15. 

Meanwhile, Rajiv will investigate the remaining mailnews interfaces for logoff,
send mail, and send document. 

A complete schedule will be made, once Rajiv completed the investigation of the
mailnews interfaces.



 

Comment 22

[Hong Kwon]

mass qa assigning all simple MAPI bugs to olgac 

Comment 23

[Hong Kwon]

*** Bug 11057 has been marked as a duplicate of this bug. ***

Comment 24

[Hong Kwon]

Adding old blocking bugs and ccs.

Comment 25

[Krishna Mohan]

Attachment: Patch for changes in existing bootstrap code for mapi support

Comment 26

[Krishna Mohan]

Attachment: New code to support mapi functionality in 6.x

Comment 27

[David :Bienvenu]

Can you attach the individual source files instead of one big jar file?

Comment 28

[Chip Clark]

Since this is a meta bug for the simple MAPI feature, posting the patch for 
MAPILogon in bug 95117.

Comment 29

[David :Bienvenu]

If you don't want to attach each file, what you can do is cvs add your new files
(but don't commit them!), then do a cvs diff -uw -N which will show the new
files as diffs.

Comment 30

[Rajiv Dayal]

Since cvs add requires write access and neither me or Krishna has it, we created 
the tar file. Anyway, we have now asked Srilatha in our group to create a patch 
with all the files in it. She will attach the patch to the Logon bug. 
Also, Krishna can u please attach any other patches/comments on the MAPILogon 
bug (or other individual bugs) instead of this major bug for MAPI support.
- thanks.

Comment 31

[David :Bienvenu]

cvs add is a purely local operation - I'm surprised it requires write access.

Comment 32

[David :Bienvenu]

My first comment is - don't use tabs.  It looks like all your files have tabs in
them. You should use 2 or 4 space indentation. You can configure msdev to not
put tabs in, and you can also use it to reformat all your files to take out the
tabs (edit | advanced |format selection)

Also, you should use the relevant mozilla conventions when possible (PR_TRUE
instead of TRUE, PRBool instead of BOOL, nsCRT::strcmp instead of strcmp. etc).
Some of your methods/files probably need to use COM conventions, but any mozilla
code, even if it's windows-only, should use mozilla conventions.

Comment 33

[Rajiv Dayal]

as suggested by Chip Clark this is MAPI main bug so i have cut-pasted the 
comments (by bienvenu 2001-08-23 18:32) from here to the Logon bug (# 95117). we 
will use that for comments for the Logon code.

Comment 34

[timeless]

it does, there's a red bean tool that lets you get around that nastiness.

fwiw cvs add of a directory is _not_ purely local, although that's no 
justification for the cvs add of a file...

cvsdo.pl from http://www.red-bean.com/cvsutils/ (actually it's from their cvs 
server, but ...) will allow you to add stuff locally w/o manually hacking the 
CVS/Entries file (which isn't actually hard if you already have an account 
somewhere so you can steal syntax, but that's kinda catch22).

Comment 35

[Rodney Velasco]

QA contact over to trix

Comment 36

[Rajiv Dayal]

Attachment: updated anlaysis and design document for MAPI support in Mozilla

Comment 37

[Rajiv Dayal]

Attachment: diagram-1 for above design doc

Comment 38

[Tiantian Kong]

Copied email below for reference:

BIG THANK YOU to Steve for offering and organizing help to the simple MAPI project.

Action items from this meeting:

   1. mscott: open bugs for unicode conversion and missing attachment
   2 [details] [diff] [review]. Rajiv: investigate registration issue for simple MAPI.
   3. Sean: Own the bug for installer.
   4. Tiantian: notify r and sr the urgency for simple MAPI.
   5. Other: see the EXCEL attachment in previous email.
   6. Everyone: discuss status about your bugs and AI for simple MAPI, at 4pm
meeting tomorrow. 

==================
Division of labor for simple MAPI ( 9/13, Thursday)					---------------------------------------------------		

Name
bug no.	
JF
95113
r of send mail,start debug mail news interface for send mail			
Scott M	99524	deliver the fix for smtp					
Rajiv/K
95116
start send doc				
Krishna
95117/95121
continue log on, log off				
Srilatha 95122	continue pref,implement r & sr comments			
Sean Su	99526	start installer					
Trix (QA)91702	start test plan for pref, and send mail, send doc.				
							
							
List of reviewer, super reviewer	
--------------------------------
					
name
r/ sr	bug no. or feature					
Rajiv
r
Pref, 95122					
Seth
sr
Pref, 95122					
Dan Veditz	r	log on, log off, 95117/95121					
Bill Law	r	xpfe/bootstrap for log on, off					
Alec
sr
xpfe/bootstrap for log on, off					
JF
r
send mail, 95113, send doc, 95116					
David B	sr	send mail, 95113, send doc, 95116					
Syd
r
installer, 99526					
Dan     sr	installer, 99526					
							
Expected results by 9/18:							
		(1) checked in code for log on, log off, and pref which has completed r, sr.					
		(2)  coding complete for send mail, send doc, installer					

critical path ( the most uncertainty):			
		(1) Scot's smtp bug, 99524	
		(2) JF's send mail, 95113	
		(3) Rajiv's send doc, 95116	

Comment 39

[Tiantian Kong]

Normally I send status to my manager by email everyweek. However, at this stage,
a lot of people are interested to receive status update, and suggested me to put
it on the meta bug. Therefore you see it here.

It may also be helpful to QA to retest and ensure those problems encountered in
development really get a robust fix. ( Trix: include test plan for these? )

Update of status as of 9/14:

xpfe/bootstrap ( Krishna)
--completed r, sr.
--submitted a patch that included one change based on sr comment. Waiting for
reply from Alec.

log on, log off ( Krishna)

--done make file changes.

To do:
--make cpp, header file changes,
--submit for second (hopefully last) round of review ( Dan Veditz) COB today
--work on r comments,
--submit to sr (Doug T)

preference bug: 95122( Srilatha)
--waiting for one more feedback from Seth's sr comment ( pref's UI part )

To do:
--registration of COM component
--save previous app as default mail client
--submit to Rajiv for r COB today
--then sr to Seth.

send mail bug: 95113 (Rajiv, Scot, JF):
--Completed investigation about the registration of COM component.
--completed send attachment as nsiFileObject.
--completed use default char set for email body.
--Scot has fixed bug 99524!!!

To d:
--deal with failure of non-unicode call from other app to simple MAPI.
--sort out the memory corruption problem.

Comment 40

[Tiantian Kong]

nsbranch+

Comment 41

[Tiantian Kong]

Simple MAPI Status (w/e 9/17):

Every to do item on 9/14 has been completed. All critical items last week has
been fixed. Cheers to the simple MAPI team!!!

New Critical items ( items with the most uncertainty)as of today:
(1) review, super review comments ( especially for pref, as the UI needs to
check in today. Seth??)
(2) testing feedback.
(3) integration of all features. Producing dll, Mozilla exe changes, etc. (
Target completion: COB 9/18)

Comment 42

[Tiantian Kong]

Added PDT status, per PDT meeting today. Once we got all r and sr, will change
it into PDT+. 

All r ans sr, please try your best to give comments within 24 hours. If no
reply, then our assumption will be within 24 hours. If you cannot do it within
24 hours, please attend the PDT meeting at 12 noon on 9/18 at the pit of bldg 21
to explain why. Many thanks.
=======================
Subject: Urgent: your review and super review comments.
Date: Mon, 17 Sep 2001 13:18:36 -0700
From: Tiantian Kong <[e-mail]>
Reply-To: [e-mail]
To: [e-mail], [e-mail],	Doug Turner <[e-mail]>, [e-mail],	[e-mail],
Rajiv Dayal <[e-mail]>
CC: Elaine King <[e-mail]>

Hi:

You got this mail because you are the r or sr of features in simple MAPI.

Pathes for these has been up on the bug. 

On behalf on PDT, I'm requesting that you provide immediate feeback. If you
cannot be back to us today, please reply by 
email, and cc Elaine King, as to when you'll be able to get back to us.

This is an urgent request, please drop everything else that you are doing. 

Thx. Elaine will be calling each of you as well. 


Rajiv, r, 		Pref, 95122					

Seth, sr, 		Pref, 95122

Dan Veditz,	r	log on, log off, 95117/95121	

Doug Turner, sr, 	log on, log off, 95117/95121	
				
Bill Law,	r	xpfe/bootstrap for log on, off	
				
Alec, sr, 		xpfe/bootstrap for log on, off 


Tiantian
=========================

Comment 43

[Doug Turner (:dougt)]

Can I get a new patch attached which includes all new files to be added (cvs
diff -uN)?  The patches in the bug appear to be stale.

Comment 44

[Tiantian Kong]

Daily status:
Completed: 
(1) Checked in 2 patches from 9609, and 95122 respectively.
(2) Send mail and send doc is working without attachment for Excel, powerpoint. 
(3) Installer coding complete. 99526
(4) Get PDT approval to check in patch for 98566 tomorrow into branch. We can
check in the trunk today. This patch checks if MAPI support dll is available, if
available, init the dll, and expose native app support method (ensureProfile( ))
from Mozilla to MAPI clients.

To do:
(1) Krishna: debug failure in send mail/doc from Word
(2) Rajiv: fix crash in send mail/doc with attachment.
(3) Sean: get r, sr for his patch for installer, and perform r for Srilatha's
pref backend patch.
(4) Tiantian: recruit testers from Mozilla and other organizations.
(5) Srilatha: rebuild the dll, get more test app. 

Critical items: finding and fixing bugs for simple MAPI.

Target: Check in all code into chunk by 9/21.

Comment 45

[Tiantian Kong]

Status update at 3pm 9/24:

(1)Focus of simple MAPI: try to get this feature work for MS Word, Excel, 
Powerpoint and Word Pad. 

(2)Plan for this week.
9/25: check in branch and trunk at the same time.
9/26: QA and bug fixing.
9/27 and 9/28: continue QA, and if basic function flow work as designed at any 
time, hand over to internal testers.

(3)r, sr turnaround has been very speedy. Great job. Thx. Please keep it up.
logon/off: sr, Doug. r, Dan.
Pref backend: r, Sean and Dan. sr, mscott.
Send doc: sr, Seth
bug 100669: r, JF. sr, mscott. (Patch for excel will be posted soon. Continue 
working on Word.)

(4) note: check all code in trunk on last Friday has not been possible because 
of unresolved issues.

Comment 46

[lchiang]

This is one of the changes agreed we needed from the PDT mtg.  Mark just PDT to
track for now.

Comment 47

[Tiantian Kong]

Status as of 5:30pm.

Lowlight: check in has not been possible today since we are still waiting for 
r/sr stamp for 95117, sr stamp for 95122. Everyone in simple MAPI team has been 
talking with, IM, emailing reviewer and super reviewer.

(1) Got PDT+ for 95113 (send mail) and 95116 (send doc)
(2) At the request of PDT, Doug is working to fix the STL problem in 95117. Dan 
is half way through his r comments.
(3) Srilatha implemented all changes from review, over to msott for sr.
(4) Got user guide from John, our tech writer.
(5) Rajiv fixed the blocker issue of 100669. Patch in review.

To do.

Krishna: work on Dan's r comments when available, work with Doug.
Srilatha: contact msott, ensure that sr stamp is obtained before noon on 9/26.
Rajiv: try to get r and sr stamp before 3:30pm on 9/26.
Tiantian: review user guide.

Doug: fix STL in 95117.
msott: sr for 95122 before noon 9/26, sr for 100669 before 3:30pm on 9/26
Dan: deliver r of 95117 today.

Comment 48

[Tiantian Kong]

Status at 5pm on 9/26.

Lowlight: We were hit by a thunder called "Turbo". PDT requested that we made a
private build from the 0.9.4 branch to fully test simple MAPI with/without
turbo, with single/multiple profile, etc.

Highligts: Got sr stamp for 95122 and 100669. Doug produced a patch to solve the
STL problem, Krishna worked over midnight, implemented all comments, and
produced a new patch for 95117. 

Comment 49

[James Rome]

can you people who are working on this let us know when (and where) a reasonably
stable build is available with it included so that we users can test it?

Comment 50

[Tiantian Kong]

Hi, James:

Sorry for keeping you and other users waiting so long. I understand your
frustration.   

Our engineers are working very hard to deliver this feature. 

Current best estimates that I have is by Monday, 10/1, to deliver a reasonably
stable build that has partial simple MAPI. Further information will be provided
when it becomes available.

We'll try to complete a private build today, then our QA will test it on Friday.
  Developers will try to fix any bugs found by QA. 

Comment 51

[Daniel Veditz [:dveditz]]

Correction to Tiantian's 2001-09-27 10:59 comment:

The PDT requested a private BRANCH, from which any number of people (including
the release team) can create test builds and examine the full source diffs, not
simply a binary test build from private sources.

Comment 52

[Tiantian Kong]

Critical items:

(1) Delivering the private build to Trix and Esther for testing today.
(2) Bug fixing. If there are a lot of bugs, may need mailnews team's help.
(3) Reaching a stable status on the private branch on 10/1.

In progress:
(1) Developers are doing unit test on the private branch. (Rajiv, Krishna, Srilatha)
(2) User guide for simple MAPI. (John, Robin, Trix, Tiantian)
(3) Updating the test cases to include cases for single/multiply profile running
with/without turbo mode.(Trix)
(4) Alias that allow people to sign up to test simple MAPI. (Elaine, Tiantian) 
(5) Investigation about security issue of sMAPI. ( Tiantian )

Comment 53

[Tiantian Kong]

Please note that a new component called "simple MAPI" has been opened, so that
bugs for simple MAPI can be opened.

Comment 54

[Tiantian Kong]

Here's a query to find all bugs about simple MAPI, including the meta bug.

http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=MailNews&component=Simple+MAPI&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&namedcmd=pdt%2B&newqueryname=&order=Reuse+same+sort+as+last+time

Comment 55

[WD]

*** Bug 102463 has been marked as a duplicate of this bug. ***

Comment 56

[Tiantian Kong]

For build and testing information, please see bug: 102570, branch landing bug

Comment 57

[Tiantian Kong]

(1)We have checked in the branch landing bug to 0.9.4. 
(2)All in progress items from previous statues has been resolved.
(3)Completed bug triage for all sMAPI bugs. 

In progress now:
Krishna: bug 101816, 102392
Rajiv: 102798, 103313, also investigate 102821 
Srilatha: 103260, 102918.
Trix / Yulian / testers : test, test, test....
Tiantian: upates to user guide, etc. 
Dan: utility to allow administer to turn on the silent send feature.

Asked Scott for help on the migrated profile bug: 102928

Comment 58

[Tiantian Kong]

One more must fix that has been assigned to Dan yesterday, bug 102795

Comment 59

[Tiantian Kong]

Update:

Checked in patches for bug 103260, bug 102821, bug 103410, and bug 102798

In progress:

bug 102392, bug 102918, bug 103313. Target date for fixing, by 10/10. 

Comment 60

[Tiantian Kong]

Srilatha is working on bug 103897, bug 103908, target 10/10

Comment 61

[Tiantian Kong]

Bug 102392, bug 103313, bug 103897, bug 103908, has all been checked into the 
branch last night.

GREAT JOB.

Comment 62

[Tiantian Kong]

Over the last couple of days, we have fixed some bugs. Among them:

bug 102389 ( which was reopened), bug 104091, bug 104275.

Investigation has been done for the following bugs, and decision has been made
to deal with them at the next release: bug 102645, bug 103230, bug 104237, bug
104256,  bug 104258, bug 104256, bug 104291, bug 104491.

In progress now: bug 103232, bug 104943.

Comment 63

[Tiantian Kong]

Another bug 104938, already has patch, r, sr, PDT+. We'll check in to the branch
today.

Comment 64

[grega]

removing nsenterprise+ keyword since this is the metabug

Comment 65

[Tiantian Kong]

Th three bugs from yesterday has been verified by Trix. 

No stop-ship bugs today.

Comment 66

[Tiantian Kong]

Since all the dependency bugs are fixed and verified in the 0.9.4 branch, and
has been baking in the branch successfully since 10/17, I'm marking this meta
bug as fixed.

Trix: add verify?

The bugs which Hong added as being blocked by this meta bug are from NS4.x.
Right now, support NS4.x is not the duty of our team. I'll talk to Greg about this.

Comment 67

[Trix Supremo]

marking verified