Mailinglist Archive: opensuse-softwaremgmt (33 mails)

[Frank Karlitschek <karlitschek@xxxxxxx>]

On 03.11.2010, at 14:29, Duncan Mac-Vicar P. wrote:

> On 11/02/2010 04:24 PM, Frank Karlitschek wrote:
> > Hi,
> >
> > 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 
> > openSUSE.
>
> 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.
>
> https://github.com/hughsie/app-install/blob/master/docs/app-install-v2.txt
>
> 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 
> repositories.
>
> The result is something like:
> http://blogs.gnome.org/hughsie/2010/09/07/linux-and-application-installing/
>
> 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 
> applet)
> ** KPackageKit will be renamed Apper or something like that
> *** Richard is open to add changes to the schema/spec if it help our neeeds.


Cheers
Frank


--
Frank Karlitschek
karlitschek@xxxxxxx




--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx