Refactor conversion
The conversion mechanism was developed with emotion conversion in mind. In order to enable other types of conversion, it needs to be refactored or extended.
My first thought was to mimic what we are doing with the analysis, and have an analogous method such as convert_entry
.
The problem with this approach is that whereas an analysis is always run, a conversion may not always need to be.
As a solution, we could add an intermediate step that selects conversions that need to be applied, and run them in series.
The selection could be handled somewhere in the core (e.g. in the extensions module) or delegated to each conversion plugin, with something like a should_convert(entry, params, other_plugins...)
method.
The other_plugins
part could tell the plugin what other conversions are already going to be applied.
In summary, these are the main ideas:
-
Avoid unnecessary conversions. Until now, we've been using only one plugin to convert each EmotionSet. i.e. if there are two candidates to convert an EmotionSet, only the first one is run. -
Keep it general enough to allow for any type of conversion (sentiment, emotion...), including conversions that act as "filters" (getting the emotion with the highest value). -
Allow users to specify the conversion they want (explicit is better than implicit) -
Avoid unnecessary computations that might slow down the service