Last Comment Bug 4394 - libmime to export QP/Base64 encoders
: libmime to export QP/Base64 encoders
Status: VERIFIED FIXED
:
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: Trunk
: x86 Windows NT
: P3 normal (vote)
: M4
Assigned To: rhp (gone)
: Katsuhiko Momoi
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-03-29 17:34 PST by nhottanscp
Modified: 2008-07-31 01:23 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description nhottanscp 1999-03-29 17:34:55 PST
QP encoder is needed in order to send Latin1 mail (M4).
Message send needs encoders from libmime through xpcom.
Comment 1 lchiang 1999-03-29 17:37:59 PST
Kat, can I put you as qa contact for this bug?
Comment 2 Katsuhiko Momoi 1999-03-29 18:06:59 PST
Sure, I just put myself in there and replace me with yours in the CC
line.
Comment 3 rhp (gone) 1999-03-29 18:09:59 PST
If anyone can note the specific function calls, that would speed the
development :-)
Comment 4 nhottanscp 1999-03-30 09:49:59 PST
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) 1999-03-30 10:14:59 PST
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 1999-03-30 11:11:59 PST
I think it's good to combine encoders into one interface.
Comment 7 rhp (gone) 1999-04-01 20:33:59 PST
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 1999-04-08 22:21:59 PDT
** 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 1999-04-09 10:51:59 PDT
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 1999-04-09 12:30:59 PDT
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 1999-04-27 17:42:59 PDT
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 1999-04-27 17:47:59 PDT
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 1999-04-27 18:35:59 PDT
** 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.

Note You need to log in before you can comment on or make changes to this bug.