> 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 > >
