4394 - libmime to export QP/Base64 encoders

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[nhottanscp]

QP encoder is needed in order to send Latin1 mail (M4).
Message send needs encoders from libmime through xpcom.

Comment 1

[lchiang]

Kat, can I put you as qa contact for this bug?

Comment 2

[Katsuhiko Momoi]

Sure, I just put myself in there and replace me with yours in the CC
line.

Comment 3

[rhp (gone)]

If anyone can note the specific function calls, that would speed the
development :-)

Comment 4

[nhottanscp]

There are empty functions defined in compose/src/msgCompGlue.cpp and used in
compose/src/nsMsgSend.cpp and nsMsgSendPart.cpp.
There are 7 functions, in libmime they're in mimeenc.cpp. Looks like init
functions return function pointers. I am not sure if this is ok in xpcom.

MimeEncoderData *	MimeB64EncoderInit(int (*output_fn) (const char *buf,
int32 size, void *closure), void *closure) {return NULL;}
MimeEncoderData *	MimeQPEncoderInit (int (*output_fn) (const char *buf,
int32 size, void *closure), void *closure) {return NULL;}
MimeEncoderData *	MimeUUEncoderInit (char *filename, int (*output_fn)
(const char *buf, int32 size, void *closure), void *closure) {return NULL;}
int					MimeEncoderDestroy(MimeEncoderData
*data, XP_Bool abort_p) {return 0;}
int					MimeEncoderWrite (MimeEncoderData *data,
const char *buffer, int32 size) {return 0;}
char *				MimeGuessURLContentName(MWContext *context,
const char *url) {return NULL;}
void				MIME_GetMessageCryptoState(MWContext *,PRBool
*,PRBool *,PRBool *,PRBool *) {return;}

Comment 5

[rhp (gone)]

Thanks! I will get on this very soon. I may change the name of the other
interface I defined called nsIMimeHeaderConverter.h to nsIMimeConverters.h and
that way, we can add these routines as we need to.

How does that sound?

- rhp

Comment 6

[nhottanscp]

I think it's good to combine encoders into one interface.

Comment 7

[rhp (gone)]

These interfaces have been exported via a new XP-COM interface in libmime. What
I've done is change the old nsIMimeHeaderConverter.h to nsIMimeConverter.h. A
detailed view of the interface can be found at:

http://lxr.mozilla.org/mozilla/source/mailnews/mime/public/nsIMimeConverter.h

Let me know if there are any problems.

- rhp

Comment 8

[Katsuhiko Momoi]

** Checked with 4/8/99 Win32 evening build **

I think that these encoders are being made available
now for sending mail -- see Bug 3994.
But I noted a problem in Bug 3994 in that while encoding is
talking place, there is also a truncation problem leading
to incomplete headers.
I don't know if this is the problem in engaging the encoder or
the encoder itself. Looking at nsIMimeConverter.h, it seems that
the line length is defined there, so the truncation problem
might reside in nsIMimeConverter.h.

We cannot look at Base64 encoding part since Latin 1 mail does not
use B (or Base64), but Japanese message display does. The B-ecoded
Japanese headers are dhowing correctly. Since nsIMimeConverter.h seems to
do both encoding and decoding, this would tend to confirm that Base64
part is also being used successfully.

I'm going to hold off on verifying this bug until more is found about
the problem in 3994.

Comment 9

[nhottanscp]

Bug 3994 is for header encoding only. This bug is about body encoding (QP,
Base64, UU).
In M4, because of the Ender problem (4388), this can be only verified by writing
JavaScript to access the message compose appcore.

Comment 10

[Katsuhiko Momoi]

We tried a suggested workaround on the latest build, i.e.
modifying msgcompose.xul directly to send out 8-bit body, but
ran into a problem which prevents us from checking on this.

I'll have to wait until some workaround is found.

Comment 11

[Katsuhiko Momoi]

Bug 5525 is now blocking the verification of this fix.
MIME-encoding should be working now but whatever we send
disappears due to Bug 5525.

Comment 12

[nhottanscp]

QP can be verified now because we can send Latin1.
Base64 cannot be tested because we have no attachment send capability.
5525 is Japanese body send bug, as we don't base64 Japanese main body, it is not
related to this bug.

Comment 13

[Katsuhiko Momoi]

** Checked with 4/27/99 Win32 build **

Thanks, Naoki, for clarification.

I'm going to mark this bug fix verified based on the test results on
"Latin 1 body send" which is properly encoded in QP.
If we want to test Base 64 encoder, then we will do
so when we have a feature working which uses this encoder.