<table><tr><td style="">knauss added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8071" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D8071#150859" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D8071#150859</a>, <a href="https://phabricator.kde.org/p/vkrause/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;" rel="noreferrer">@vkrause</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>But that would tie processing and rendering always together to the same plugin, wouldn't it? In which case the entire exercise of splitting this up becomes kinda pointless, we could just render with the same plugin that managed to succeed in processing.</p></div>
</blockquote>

<p>I think in most cases they are connected yes: for vcard, WKS, calendar there is for sure things, that should be done in Processing and not at render step.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Also, look at it from the plugin developer POV: In this scenario I need to implement process() to decide if I want to deal with it (fair enough), implement my own sub-class of TextMessagePart or AttachmentMessagePart (without any extra data, everything I need is already there, so that's just busy work), fill it with the same logic that TextPlainBodyPartFormatter has presumably (that's highly error prone, that code deals with sign/encrypt state for example), and then I eventually get that passed to my render() method that actually does what my plugin wants to do.</p></blockquote>

<p>well that is a valid point, the formatter need to get much easier! btw. the distintion between AttachmentMessagePart/textmessagepart is also something that really should be removed, the descition if what is an attachment should be done later in ther rendering step.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>As most plugins are purely dealing with rendering, I think this deserves a more convenient API. Ie. leave processing to things like crypto that actually manipulates the hierarchy, and to do things like determining what's the main body text etc, and allow rendering to work on top of that result.</p></blockquote>

<p>Okay we don't come to a good conclusion...</p>

<p>So be pramatic: So far we don't have that many plugins, and these need at least be updated to the recent interface. And this patch helps to do the work.</p>

<p>We can later still make the getter as deprecated and rework, if we have more clearer picture with the plugins...</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R94 PIM: Message Library</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8071" rel="noreferrer">https://phabricator.kde.org/D8071</a></div></div><br /><div><strong>To: </strong>vkrause, knauss<br /><strong>Cc: </strong>KDE PIM, dvasin, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>