emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RMAIL, MIME-related bug


From: Alexander Pohoyda
Subject: Re: RMAIL, MIME-related bug
Date: Thu, 16 Oct 2003 15:14:55 +0200 (MEST)

> > The problem is that we have to do this
> > after the mail is reformated, but there is no valid MIME message after
> > the rmail-reformat-message call: the message is broken into two parts
> > by the EOOH marker.
> > To be able to MIME-parse it, I have to glue the message back and
> > delete the "simplified" header in between.
> 
> I don't understand why is it important to have the message in its
> original pre-`rmail-reformat-message' form. 

Because, after reformatting it is not a MIME message anymore!

You agreed that we can do some mail processing before reformatting
and you agree that we have to do even more processing after reformatting.
Thus, if we want to use the same functions to do the job, we have to
teach them to ignore this "simplified" header. Now, MIME is recursive and
this means that we have to do this ignoring in every media type handler.
Is there anything we gain with this implementation?

OK, this may not be that important. I just don't see a reason why do we
have to reformat the message just to ignore this reformatting later.
Reformatting only introduces an obstacle. Why to do that?

And, as I mentioned before, I cannot re-use the old machinery (namely:
deleting header fields), thus header-field hiding will be necessary anyway.
So why not to hide header fields everywhere instead of deleting them
and reformatting the original message?


> All the necessary MIME information is still there, part of it before
> EOOH, part of it after. 

Yes, all information is there, but the structure is not.
The structure is broken. There is no MIME message anymore.

> So you ought to be able to figure out how to process the
> message, right?  What am I missing?

Right, everything is possible. The only question is: does it make sense?

In the end, if there is no other acceptable solution, I will have to do it
this way.

-- 
Alexander Pohoyda <address@hidden>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72
 15 54 5F 62 20 23 C6 44





reply via email to

[Prev in Thread] Current Thread [Next in Thread]