The current implementation is mind, is that we change otp so, that all rendering parts are get outsourced into plugins and return a tree of objects that can rendernd aterwards

Let's start think about the way we want to reach.

Currently it is used like that (this is a synced version of a async process, the idea is that the second rendering is done when it is ready - this makes the example more compact than creating a comple class):

KMime::Message::Ptr msg = <the mail>;
NodeHelper nodeHelper;
EmptySource emptySource;
emptySource.setAllowEncryption(true);
{
    OEventLoop loop;
    ObjectTreeParser otp(&emptySource, &nodeHelper);
    connect(&nodeHelper, SIGNAL(update(MessageViewer::Viewer::UpdateMode)), &loop, quit());
    otp.setAllowAsync(true);
    otp.parseObjectTree(msg.data());
    loop.exec(); //Wait for encryption/signing job to be finished
}

{
    ObjectTreeParser otp(&emptySource, &nodeHelper);
    otp.setAllowAsync(true);
    otp.parseObjectTree(msg.data());
}

• NodeHelper holds the persistant data, if we have async part in it
• OTP is only a throw-away parser
• Source are settings for the rendering part not for the parsing

The new interface should look like following:

KMime::Message::Ptr msg = <the mail>;
NodeHelper nodeHelper;
EmptySource emptySource;
emptySource.setAllowEncryption(true);
{
    OEventLoop loop;
    ObjectTreeParser otp(&nodeHelper);
    connect(&nodeHelper, SIGNAL(update(MessageViewer::Viewer::UpdateMode)), &loop, quit());
    otp.setAllowAsync(true);
    otp.parseObjectTree(msg.data());
    otp.render(&emptySource);
    loop.exec(); // Wait for encryption /signing job to be finished
}

{
    ObjectTreeParser otp(&emptySource);
    otp.setAllowAsync(true);
    otp.parseObjectTree(msg.data());
    otp.render(&emptySource);
}

This works for text and html output, but for qtquick we return a tree of QObjects with QPROPERTIES. This tree is interally anyhow, to refelct the contrete visual represantation of the mail. The render step can than also be moved easily to grantlee.

Parsing step

Internally otp interate over each node and ask BodyPartFormatterFactory to get a BodyPartFormatter for the matching mediaType/subType of the node. BodyPartFormatterFactory is a plugin interface where you can register BodyPartFormatter for mediaType.

• What about multiple BodyFormatter for the same mediaType? Does that makes senśe?

and runs a BodyFormater accoring to the nodes mediaType (BodyFormatter.process) as result we get a tree of MessageParts, that represent the mail visualy and has nothing to do with the represantation in the mail structure. For example for an encrypted+signed mail with attachments:

->enc block
    -> signed block
         -> phabricator block
         -> signed att1
              -> diff block
        -> signed att2
   -> non signed att1
-> non enc att1

But we also need a second level of plugins, that do not have own mediaType/subType for example Inline PGP, Diff View or a Phabrictor/Mailman visual block. All visual string output is performed via own method (writeBodyStr/writeBodyString). So we need there another Pugin infratrcture that process on the simple text. and splits the single string into multiple Blocks.

foreach(auto formatter, formatters) {
      if(formatter.handles(text)) {
          auto listBlocks = formatter.process(text);
          break;
      }
}

or use the Factory pattern here, too?

For Phabricator/Mailman own view we must act on special headers of the main part. So we would either need a own BodyPartFormatter for that or add a third plugin infrastructor on the text/plain process. Like it is done now for Mailman

!isMailmanMessage(node) || !processMailmanMessage(node)

General approach looks good to me.

My idea for the multiple plugins for the same mimetype problem (most probably text/plain) was to enable that by having a sorted list of plugins per mimetype, by giving them some form of numeric priority. The generic text/plain plugin would be the last in the chain.

The plugins would then be tried one after the other, as you suggested as well. One approach when the first one accepts a node is to stop there, but one could also consider continuing, if their output is not a special part object, but something that can be fed back into a plugin. Conceptually as if the output would be an expansion in the KMime::Content* tree, same as the crypto containers do it. Then we can chain the plugins arbitrarily until we hit the default one in the end. I know it's technically not as easy as that, I just want to outline the concept here :)

For rendering it's slightly different, you need to abort after a line has been rendered, you definitely don't want to end up in the default formatter and render again. We therefore probably want to expose the default rendering methods for other plugins to use (render a text line with emoticons, render an attachment box, etc).