Comment 3 for bug 681471

Revision history for this message
Michael Nelson (michael.nelson) wrote : Re: [Bug 681471] Re: URLs need to be (more) cacheable

On Wed, Dec 1, 2010 at 11:10 AM, Matthew Paul Thomas <email address hidden> wrote:
> (2) You'll be able to rate not just applications, but any software, e.g. fonts, themes, developer libraries. So I think it would make more sense to leave it as just /reviews.

This first part of the path is so we can tell apache - anything that
starts with /reviews can be handled by the rnr-server - ie. it
identifies the project.

So we can leave it as /reviews, but if we later expose reviews via the
UI, we'll need a second path segmant with '/reviews', ie.
/reviews/reviews/3/ as the unique path to a review item. Similarly, a
moderation resource would be /reviews/moderations/2/. Reviews for a
specific package would be something like
/reviews/packages/apache/reviews/ etc.

Theoretically we can get rid of the initial /reviews completely *if*
we will never want to use the domain for any other applications (ie.
we can tell apache to send all requests to rnr-server - this is what
we do for software-center.ubuntu.com), or are happy to have
complicated rules for apache like, send everything that starts with
'/api' or '/reviews' or '/moderations' or '/packages' to the
rnr-server - which needs updating each time we add another path
(unlikely). I just assumed that with a domain like
developer.ubuntu.com we need a project identifier as the first path.

Maybe there are other options that others can recommend, but if we
don't know whether we'll want to use developer.ubuntu.com for other
apps, then I think we need a project identifier first, even if it is
'/reviews' with the above issues, or simply '/r/' (ie. /r/reviews/1/
or /r/moderations/1/ etc.)

> (3) At <https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews#moderating> I suggested that the moderation interface appear at the application's top level, <https://developer.ubuntu.com/reviews>. Is there something more important that belongs at that top level?

Currently, as we won't have any other items exposed (yet), we can use
the top-level (/reviews or whatever - see above) as an overview of
relevant moderation info for the current user (bearing in mind that it
might change if we do expose other stuff such as reviews or software
via the web interface later), but not for a general URL representing a
filter-able collection of all moderations (which is what I meant above
- sorry if it wasn't clear).