<table><tr><td style="">krake 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/D22352">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/D22352#494026" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D22352#494026</a>, <a href="https://phabricator.kde.org/p/dfaure/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@dfaure</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>I don't think output codec is needed, toLocal8Bit/qPrintable is the expected output codec for commandline programs.</p></div>
</blockquote>

<p>Output codec was mostly important for certain outputs, e.g. VCard 2, which doesn't have a standard codec.<br />
For now I agree we should be fine with either of these two methods of creating "local" output.</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>So the current two ideas are --decoded (default raw) and --raw (default decoded). I chose the former to avoid breaking existing users, but if you guys prefer, I'm also OK with the latter.</p></blockquote>

<p>I prefer "raw" as the exception due to the command being "show", i.e. "human consumable".<br />
"raw" is more like "internal format, you have been warned".</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>This is playground after all (unfortunately...).</p></blockquote>

<p>Originally I was planning to get it into pim/console just like kabcclient and konsolecalendar used to, but the multi data nature makes it much more complex than these two and I never got around to really think about the API in enough detail to risk "official" releasing.</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>And yes if someone wants to choose between vcard and csv for contacts, that would be a --contact-format switch. This way it works even in an unlikely mixed folder, but more importantly it's easier to document (contact-format lists the contact formats, event-format lists the event formats etc.).</p></blockquote>

<p>Documentation/discoverability is a good point.</p>

<p>For the generic switch I was thinking maybe something like</p>

<p>--output-format email=full,contact=vcard</p>

<p>i.e. allowing the argument to be a list of sorts.</p>

<p>Encountering different types of items is unlikely, but the command allows to specify a list of item IDs, which could even come from different collections.<br />
So it is a decision of either not allowing/supporting different types in the same invocation or being capable of specifying options individually.</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>Hmm, does this mean instead of --decoded, what I want is <tt style="background: #ebebeb; font-size: 13px;">--email-format decoded</tt> ?</p></blockquote>

<p>That was my initial take, but now I think quoted printables should always be decoded unless specifically requested not to.<br />
I.e. if you want to process the item's payload with a mail capable program you simply use "--raw", if you are manually parsing information of any sort you probably don't want to deal with quoted printable encoding yourself.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R723 Akonadi CLI Client</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D22352">https://phabricator.kde.org/D22352</a></div></div><br /><div><strong>To: </strong>dfaure, marten, krake<br /><strong>Cc: </strong>kde-pim<br /></div>