[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Review Request 129298: RFC: supporting dependencies on KPackage
From: Dan Leinir Turthra Jensen <admin () leinir ! dk>
Date: 2016-11-01 13:42:15
Message-ID: 20161101134215.15979.61968 () mimi ! kde ! org
[Download RAW message or body]
--===============1137457448407641913==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > <https://git.reviewboard.kde.org/r/129298/diff/1/?file=483564#file483564line14>
> >
> > if kns ends up using ids, maybe the server should be specified as well, as the id \
> > would be server-dependent?
>
> Aleix Pol Gonzalez wrote:
> 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.
> I don't think it should be server-dependent. If anything, if the user changes the \
> contents server, it might not find the component.
> Dan Leinir Turthra Jensen wrote:
> 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".
> Marco Martin wrote:
> 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
...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).
- Dan Leinir Turthra
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129298/#review100442
-----------------------------------------------------------
On Oct. 31, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129298/
> -----------------------------------------------------------
>
> (Updated Oct. 31, 2016, 5:09 p.m.)
>
>
> Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and Marco \
> Martin.
>
> Repository: kpackage
>
>
> Description
> -------
>
> 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.
> 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
>
> Diffs
> -----
>
> autotests/CMakeLists.txt 395b16e
> autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION
> autotests/data/testpackagesdep/metadata.json PRE-CREATION
> autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION
> src/kpackage/config-package.h.cmake 61f2f0c
> src/kpackage/private/packagejobthread.cpp 0a0cc01
> src/kpackage/private/packagejobthread_p.h 1babf0b
>
> Diff: https://git.reviewboard.kde.org/r/129298/diff/
>
>
> Testing
> -------
>
> 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.
>
> Thanks,
>
> Aleix Pol Gonzalez
>
>
--===============1137457448407641913==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<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>
</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;">...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> <br />
<p>- Dan Leinir Turthra</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>
--===============1137457448407641913==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic