The default bug view has changed. See this FAQ.

libmime to export QP/Base64 encoders

VERIFIED FIXED in M4

Status

MailNews Core
MIME
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: nhottanscp, Assigned: rhp (gone))

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

18 years ago
Target Milestone: M4

Comment 1

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

Updated

18 years ago
QA Contact: 4080 → 1308

Comment 2

18 years ago
Sure, I just put myself in there and replace me with yours in the CC
line.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

18 years ago
If anyone can note the specific function calls, that would speed the
development :-)
(Reporter)

Comment 4

18 years ago
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;}
(Assignee)

Comment 5

18 years ago
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
(Reporter)

Comment 6

18 years ago
I think it's good to combine encoders into one interface.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

18 years ago
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

18 years ago
** 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.
(Reporter)

Comment 9

18 years ago
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

18 years ago
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

18 years ago
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.
(Reporter)

Comment 12

18 years ago
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.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 13

18 years ago
** 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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.