as part of my work on Likes I have started in 12.7 to work on the Ratings extension, to allow using it for Likes, and first I started to notice some problems in the API, and second after talking with Vincent it appeared that we might want to re-design it in order to allow generic ratings usage throughout XWiki.
With all that in mind, I wrote a design page to summarize the usecases I would want for a Rating API taken into account the already existing API and the needs I discovered with Likes, and the ones discussed with Vincent. Here’s the design page: https://design.xwiki.org/xwiki/bin/view/Proposal/RatingsnewAPI
Based on that, there’s several choices that I want to discuss here to ensure we agree on them.
Proposal 1: create a Rating API that allows to create instances of RatingManager
That’s the actual basis of the discussion on this new design (UC1 of the design page): the idea is to be able to create a Like extension (at least the backend) just by instantiating a new RatingManager with some information.
Do we all agree on that?
Proposal 2: Move the actual Rating extension to the attic and create a new one
I’ve not put it in the design page yet, but it seems to me that it would be far more easy to move the actual Rating API extension to the attic and develop a new one, compared to deprecate stuff / put it in legacy and move like that.
The reason is that preserving the backward compatibility here won’t be really easy, especially since there are very few tests and that I want to drop some support (see below).
So basically if I want to keep the actual API and work on it, I’d need almost to first cover it with test before starting the changes. It’s doable, but I think I will lose lots of time for doing it.
Also note that Rating API is not recommended (as well as Rating Extension).
So do we agree to move the actual Rating API to the attic (pretty sure it won’t be needed for the Rating UI) and to create a new one?
Note that we could decide to rename the parent module
xwiki-platform-rating (instead of
xwiki-platform-ratings) and to create a new Rating API named
xwiki-platform-rating-api: we would avoid name conflicts and keep a good name.
Proposal 3: Dropping support of storing Ratings info into xobjects
One of the reason for proposing to move the existing API to the attic is also to drop support of storing Ratings as xobjects. This is clearly not a scalable solution for storing such information.
As proposed in the design page (see UC9), I propose that we allow first storing Rating information in Solr since it’s already implemented, but we can also improve it by providing a dedicated hibernate mapping for Ratings.
Note that this drop of support of xobjects also imply necessarily a migration tool for old ratings (See UC13)
New design open questions
Besides those proposal there is also a few open questions in the design page that I’ll try to summarize here to simplify the discussion:
- Do we want to keep supporting the Users’ reputation usecase (UC11): I’m personally not sure if it’s needed or not, it’s not really documented or used in the current extension AFAICS.
- Do we want to allow Admin to change the Storage of Ratings (see UC9), or do we want to consider that several storage implementation are provided for Ratings and it’s the developer of the extension who chose which storage will be used? Note that allowing Admin to change the Storage would imply to have the migration mechanisms.
- Do we want to have a Rating Right to be configured globally, or do we want to be able to have custom Rights depending on the RatingManager instance (e.g. a Rating Right, a Like Right, etc) (see UC10)