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. > 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. > 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 > Lastly, for icons, if legal says it's inacceptable to have a > package/repodata blob with all of them, we could download them from > packagedb on demand, where apparently you have them. Yep. I believe that was an option that spot gave. If this is the route we go we probably want to explore with spot what optimizations we could do that would be okay from a legal standpoint (For instance, could a user request a list of packages' icons and then we supply all of those icons as one download via pkgdb.) > I doubt that > though, as other distros are packaging them without problems. > There are other things that other distros do that we don't for legal reasons. We have to play by the rules that Fedora Legal (pretty much spot) or Red Hat legal (transmitted to us via spot) hands down to us even when it puts us at a disadvantage with respect to what other distros do who have a different legal team with differing legal advice. Which is not to say that you shouldn't talk to spot about where the lines that we cannot cross lie -- you may be able to figure out an innovative way to satisfy the legal requirements and provide a good user experience that way. > > There's also a good chance that we'll encounter some pieces of data that > > a software center would like to use but that we aren't storing or making > > public at the moment. If it's already present in the packages or something > > that users would contribute we can look into how to make that available for > > the software center to use. > > > > This will take coding time, however, so it would be something that you (or > > whoever is interested in working on backend support for the software center) > > would need to be willing to sink some time into. > > That's exactly why I'm here: to offer my time to build a great app > software installation story for the next Fedora. > Excellent! -Toshio
Attachment:
pgpvu9GytWHMK.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
