Ratings and Reviews server

Bug #688112
Comment #6

Comment 6 for bug 688112

Revision history for this message

Anthony Lenton (elachuni) wrote on 2011-01-19:

Discussed the implementation for this with noodles.

We really don't want to rely on GET arguments as it would prevent caching.
Instead we're going to:
* Add 'version' to the current url patter for requesting reviews
* Allow all parameters in the url (language, origin, distroseries, version) to be specified as "any", that'll retrieve reviews for any value of that parameter.
* Any parameter that's not specified as "any" will retrieve only reviews for that value of the parameter. That is, all parameters will affect the retrieved set of reviews, not just the order in which they're returned.

With this approach, to simulate a specific ordering of the reviews, the client app can:
* First request the specific reviews for the exact language, version, architecture and distroseries the user has.
* Retrieve paged responses with those reviews until they run out.
* Once those have run out, it can go relaxing the conditions one at a time (or all together) to get larger review sets. When each page of reviews is retrieved, it should check to remove any reviews that are already being shown to the user.

Some reviews will be returned in multiple result sets -- for example, reviews for the exact version, architecture and language of the user will also be returned when requesting reviews for the exact version and architecture in any language. As all reviews come with their id, the client app can avoid showing repeated reviews to the user. Note that this problem already exists with almost any paginated approach, as a new review could come in that pushes the last review from page N on to page N+1.

If reviews are going to be shown in a single growing scrolled area, then having to remove one or two reviews from a page of retrieved reviews may not be a problem. If we really want to show X new reviews every time, one way to provide this would be to retrieve additional pages until you've got at least X new reviews to show, and keep any reviews after the first X around to show on the next page, if it is eventually requested by the user.

Discussed the implementation for this with noodles.

We really don't want to rely on GET arguments as it would prevent caching.
Instead we're going to:
 * Add 'version' to the current url patter for requesting reviews
 * Allow all parameters in the url (language, origin, distroseries, version) to be specified as "any", that'll retrieve reviews for any value of that parameter.
 * Any parameter that's not specified as "any" will retrieve only reviews for that value of the parameter.  That is, all parameters will affect the retrieved set of reviews, not just the order in which they're returned.

With this approach, to simulate a specific ordering of the reviews, the client app can:
 * First request the specific reviews for the exact language, version, architecture and distroseries the user has.
 * Retrieve paged responses with those reviews until they run out.
 * Once those have run out, it can go relaxing the conditions one at a time (or all together) to get larger review sets.  When each page of reviews is retrieved, it should check to remove any reviews that are already being shown to the user.

Some reviews will be returned in multiple result sets -- for example, reviews for the exact version, architecture and language of the user will also be returned when requesting reviews for the exact version and architecture in any language.  As all reviews come with their id, the client app can avoid showing repeated reviews to the user.  Note that this problem already exists with almost any paginated approach, as a new review could come in that pushes the last review from page N on to page N+1.

If reviews are going to be shown in a single growing scrolled area, then having to remove one or two reviews from a page of retrieved reviews may not be a problem.  If we really want to show X new reviews every time, one way to provide this would be to retrieve additional pages until you've got at least X new reviews to show, and keep any reviews after the first X around to show on the next page, if it is eventually requested by the user.