<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/129298/">https://git.reviewboard.kde.org/r/129298/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On October 31st, 2016, 5:19 p.m. UTC, <b>Marco Martin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/129298/diff/1/?file=483564#file483564line14" style="color: black; font-weight: bold; text-decoration: underline;">autotests/data/testpackagesdep/metadata.json</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">14</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="nt">"X-KPackage-Dependencies"</span><span class="p">:</span> <span class="p">[</span> <span class="s2">"appstream:///eog-light-theme"</span><span class="p">,</span> <span class="s2">"kns:///colors.knsrc/1159726"</span> <span class="p">],</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">if kns ends up using ids, maybe the server should be specified as well, as the id would be server-dependent?</p></pre>
</blockquote>
<p>On November 1st, 2016, 1:31 a.m. UTC, <b>Aleix Pol Gonzalez</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I'm not sure, either way we need changes in the KNS API, as the current search in place won't work. I'd prefer if we could use rdn-like notation on kns.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I don't think it should be server-dependent. If anything, if the user changes the contents server, it might not find the component.</p></pre>
</blockquote>
<p>On November 1st, 2016, 8:33 a.m. UTC, <b>Dan Leinir Turthra Jensen</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Hmm... a knsrc points to a providers file, which in turn can hold more than one provider. The providers in the provider file have an ID, so perhaps we can use that? So we'd end up with e.g. kns://colors.knsrc/api.kde-look.org/1159726 instead. While the api.... bit looks like a server address, it's just the ID as found in the providers file (and might be any string, technically), and so that would be enough (just) to uniquely identify the item as found on a provider which (like with the kde store) might have multiple "servers".</p></pre>
</blockquote>
<p>On November 1st, 2016, 1:11 p.m. UTC, <b>Marco Martin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">could a content be identified like org.joe.beautifulicontheme ?
then the server having some function to resolve org.joe.beautifulicontheme to its id like 137345</p></pre>
</blockquote>
<p>On November 1st, 2016, 1:42 p.m. UTC, <b>Dan Leinir Turthra Jensen</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">...what server? That is just another string ID (technically the number that you get in OCS is just a string, and at least one implementation (MidGard) uses that fact). i really don't see how we can get away with having anything less than two string IDs (server ID as defined in a providers.xml, and content ID as unique to that provider) to uniquely identify a content item... i also don't really see why it'd necessarily be better, in any real way other than aesthetics of the link, to have anything more concise than kns://knsrcfile/providerID/contentID (and possibly kns://providerID/contentID in cases of using the default provider as defined by kns internally, which resolves to using KDE's providers.xml).</p></pre>
</blockquote>
<p>On November 2nd, 2016, 5:03 p.m. UTC, <b>Aleix Pol Gonzalez</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I'll come up with a patch to search-by-id, I guess everything will look much more clear afterwards.
Nevertheless, I think it's clear that passing a providerID bypasses the provider abstraction.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">If we want to make sure a specific package is installed, maybe it would make sense to add a 3rd plugin which is <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">http://</code> or even <code style="text-rendering: inherit;color: #4444cc;padding: 0;white-space: normal;margin: 0;line-height: inherit;">ocs://</code> that assume the resource is a KPackage.</p></pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">so, if the dependency is a library and whatnot (qtcurve style comes to mind) the dependency would be an appstream id, otherwise ocs://providerId/contentId</p></pre>
<br />
<p>- Marco</p>
<br />
<p>On October 31st, 2016, 5:09 p.m. UTC, Aleix Pol Gonzalez wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and Marco Martin.</div>
<div>By Aleix Pol Gonzalez.</div>
<p style="color: grey;"><i>Updated Oct. 31, 2016, 5:09 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kpackage
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Makes it possible to specify components to be installed together with a KPackage. They will be specified by a url, we'll have handlers for any kind, making reasonably extensible and doesn't tie us to a technology.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In this repository I created two Proof of Concept of such handlers, one for the appstream urls and one for KNS: kde:scratch/apol/kpackage-install-helpers</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">None. just builds. It's a proof of concept, not even the test I added was tested, it was just to display what it could look like.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>autotests/CMakeLists.txt <span style="color: grey">(395b16e)</span></li>
<li>autotests/data/testpackagesdep/contents/ui/main.qml <span style="color: grey">(PRE-CREATION)</span></li>
<li>autotests/data/testpackagesdep/metadata.json <span style="color: grey">(PRE-CREATION)</span></li>
<li>autotests/data/testpackagesdep/testpackagesdep.testappdataxml <span style="color: grey">(PRE-CREATION)</span></li>
<li>src/kpackage/config-package.h.cmake <span style="color: grey">(61f2f0c)</span></li>
<li>src/kpackage/private/packagejobthread.cpp <span style="color: grey">(0a0cc01)</span></li>
<li>src/kpackage/private/packagejobthread_p.h <span style="color: grey">(1babf0b)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/129298/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>