Ratings and reviews implementation

On 2010-02-03 mvo and barry sketched out a design to support ratings and reviews for Lucid (an LTS). Here are our notes.

Overview

We're going to (ab)use Launchpad answers as the database for ratings and reviews. Every reviewable application will be linked to a question and we'll store individual reviews as comments in the question. User reviews will be inputted on the desktop through Software Center and will be submitted directly to Launchpad via the API. We'll deploy a new service, likely called reviews.ubuntu.com that will provide application reviews via HTTP GET as one big file of XML. reviews.ubuntu.com will talk to LP API to access and collate question comments to prevent hammering the LP database, because it can cache the read-only XML review files.

Mapping applications to questions

Questions have a number and are associated with a language. We need to map reviewable applications on the desktop to a question number. We'll do this with a 4-tuple of:

• package_name - the binary package name
• application name - the application name. this is necessary because binary packages can contain more than one application
• application version - the (major.minor?) version number of the application on the desktop
• distro name - e.g. Lucid

This mapping will not be stored explicitly in LP. Instead, reviews.u.c will maintain the mapping and use HTTP and URL trickery to expose this mapping to Software Center.

Downloading reviews for display

When Sheila wants to view the reviews for Emacs, she uses Software Center. S/C generates a URL from the 4 pieces of information above, plus the language she wants to see the reviews in. The URL is something like::

• http://reviews.ubuntu.com/lucid/emacs/emacs/23.1/en

If some reviews exist for this application, r.u.c will know what question number this is associated with (because it's already retrieved that mapping). r.u.c will respond with an XML file containing the entire current review stream for the application. The response will include the question number, which is required for submitting reviews. Software Center will parse the returned XML file and present it nicely to Sheila in her S/C interface.

If no review exists yet for the application, r.u.c needs to inform S/C of this, but this introduces a race condition. For example, if Bob wants to review the same version of Emacs as Sheila, who wins? Here are some alternative approaches (comments and other ideas welcome):

Issue a 404

r.u.c could issue a 404 which S/C would take to mean there are no reviews of that application yet. S/C would then allow Sheila to review the app and it would submit a new question to LP with her initial review. How r.u.c discovers this new question and associates it with the application review is discussed below. If Bob also submits a first review before r.u.c discovers Sheila's review, we'll now have two questions in LP which contain the reviews for Emacs.

We would have to expose an API in LP that r.u.c would call to merge the two questions. Probably the question with the lowest number would win. LP would merge the comments from the second question with the first, and then mark the first as invalid. r.u.c would know that the application is mapped to the first question.

The window of opportunity for this race is probably fairly small, since there are 30,000 reviewable applications in Ubuntu, but maybe only a few thousand very common ones. As the review database warms up, there will be fewer popular applications that have not yet been reviewed.

Pre-populate on first request

It could be that

XXX