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.sqlite.gz 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/repodata/) Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
