Thanks a lot for the explanation!
> The problem with g_mime_message_get_body() is that it made a lot of
> assumptions about the structure of the message (meaning it was pretty
> naive). Because of this, it wouldn't properly work on all messages.
As Dirk mentioned in the earlier post, the body is obvious in 99% of cases.
I would say that you can define the body part with a given email. I like
the new API, but when you have time, if you can list the cases where body
can't be clearly defined, it will be good information. Off hand, I can
iterate the following (that's probably outside of that 99% :)):
1. Delivery-status Notification message
In this case, the first human readable part should be the body. The
2nd part being "message/delivery-status" and 3rd part "message/rfc822".
2. If the body is itself a "multipart/alternative"
I agree that we will need more API to decide on the appropriate
"body" to render.
3. A S/MIME encrypted message.
In this case, it's not multipart. But since "Content-Disposition"
will look like this
Content-Disposition: attachment; filename="smime.p7m"
I would consider it has empty body and one attachment.
But other people might dice the same message differently, so the current
API is better.
- Junping