Il giorno sab, 03/12/2011 alle 22.58 -0800, Toshio Kuratomi ha scritto:
On Sat, Dec 03, 2011 at 04:13:37PM +0100, Giovanni Campagna wrote:
> Il giorno ven, 02/12/2011 alle 16.37 -0800, Toshio Kuratomi ha scritto:
> > On Fri, Dec 02, 2011 at 09:39:31PM +0100, Giovanni Campagna wrote:
> > >
> > > packagedb seems an interesting project, for storing ratings and reviews,
> > > and it could be a candidate to replace the Ubuntu backend. Is there some
> > > documentation somewhere? Does it provide some webservice API (REST,
> > > JSON, SOAP, anything)
> > >
> > It does. Many of the URLs that you can use to view information in a web
> > browser will return the equivalent information as JSON data. Not all of the
> > URLs are fast enough for what you may want to do with them now, though -- we
> > may want to craft some custom methods that give you the information you need
> > faster or in bulk. Another option for some of the things is to have users
> > enter it into the packagedb but to export it via the repodata. This was
> > done for the tag information for instance. From reading one of Richard's
> > review request bugs, it looks like people wished to do the same thing with
> > icons but there were possible legal problems with that approach (the legal
> > problem seemed to cover distributing the icons in either the repodata or
> > a package :-( ) so you'd probably need to pioneer a different approach
here.
>
> Uhm...
> curl -H "Accept: application/json"
>
https://admin.fedoraproject.org/pkgdb/applications/Terminal results in
> 500 Internal error.
Yep. I said many URLs. If you want to enable this for this URL we just
need to add an
@expose('json')
decorator to that method. But, I'm not sure if that URL will serve your
purposes or not... my experience is that it is a bit slow as currently
implemented. Plus you'd need to query the packagedb for every package
you're looking up which introduces the latency of round-tripping to the
server and back. This may be a good place to start and then after you
understand where the bottlenecks are, you may want to work on some custom
pkgdb-server methods to aggregate data.
I was thinking to use that url to find reviews and screenshots for each
application. This is something that software-center shows for each app
individually, so making a separate request is not a problem.
As for ratings/icons, we may need aggregate data instead, except that
still
> Also, packagedb seems to be coalescing different packages and
apps in
> one (same example: konsole, gnome-terminal and xfce4-terminal are all in
> the same page).
>
Yep. This is a pseudo-bug. Because of the way people have been
interpreting the spec for .desktop files, all of these provide .desktop
files where the name is "Terminal". So they're all placed on the same
page.
This could be fixed in the .desktop files (Judging from past experience,
I think that's a losing effort). Or someone could code up some other ways
of extracting and reconciling this information. There are other things that
could be enhanced in this. For instance, there's currently no extraction or
recording of information about applications that lack a .desktop file.
That's wrong, as explain by Freedesktop menu spec. You should group
applications according to the desktop file id, which is the desktop file
path, minus /usr/share/applications, with .desktop stripped and with /
replaced by -. This way, gnome-terminal (which
has /usr/share/applications/gnome-terminal.desktop) becomes
gnome-terminal, while konsole (which
has /usr/share/applications/kde4/konsole.desktop) becomes kde4-konsole,
and no conflicts are possible (otherwise, you would get a menu conflict
and/or a rpm file conflict).
Name, GenericName, X-GNOME-FullName, etc. are user visible strings and
should not be used as identifiers.
> As for repodata, you mention tags, but I can't find them
here, in
> primary, comps or other (and I don't see anything else in mirrors).
>
I hit a mirror and browsed around. Here's the one for the F16 x86_64 update
repo:
http://mirrors.xmission.com/fedora/updates/16/x86_64/repodata/pkgtags.sql...
Interesting. In fact, the file exists, but only for updates repo, not
for fedora. Is there a reason for that?
(I'm looking at
http://mirrors.xmission.com/fedora/releases/16/Everything/x86_64/os/repod...)
Giovanni