Mailinglist Archive: opensuse-softwaremgmt (33 mails)
|< Previous||Next >|
Re: [softwaremgmt] Our software store
- From: Frank Karlitschek <karlitschek@xxxxxxx>
- Date: Thu, 4 Nov 2010 11:21:36 +0100
- Message-id: <7F68E087-1A87-4361-B061-02A198F361E4@xxxxxxx>
On 03.11.2010, at 14:29, Duncan Mac-Vicar P. wrote:
On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
yes. We don´t have an website for this project yet. :-)
But I indeed suggest to use the OCS API and one of the existing client for
BTW, as we are also looking into dropping our KUpdaterApplet custom
PackageKit client and using the upstream KPackageKit, I was researching how
to make those nice clients show applications. I was shocked with all the
infrastructure that is already there.
Is the app-install specification of PackageKit, drafted by Richard and
Sebastian Heinlein (so two different distros already).
The original idea is to have one package per repo with the application
metadata, that ships the data that is added to
/var/lib/app-install/desktop.db, however I never liked this solution.
The nice thing is: KPackageKit already show the applications automatically if
that database is there.
The thing is: We could have a small tool that queries the OCS API for the
openSUSE applications (may be passing some additional HTTP headers like the
distro version) and write this database. This could be done as a cron job
even. If that does not work we still can try other approaches, like
generating app metadata once from the APIs and shipping those in the
The result is something like:
Having the client tools supporting this, plus a way to install the app from
the web appstore or the GHNS client (what Frank mentioned in the previous
email) would give us a great concrete starting point. What do you think?
This sounds interesting.
The drawback of a static db approach is that the more interactive features like
rating, comments, suggest application to friends, social features and other
advanced features do not work.
This was the approach we had with the old GHNS where we used static xml files
for the package data. Now KDE switched to OCS as real REST based client/server
protocol where more interactive features are possible.
I think OCS is the more powerful approach.
* Of course for us, in addition gives us the ability to drop the updater
** KPackageKit will be renamed Apper or something like that
*** Richard is open to add changes to the schema/spec if it help our neeeds.
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx
|< Previous||Next >|