Tags support in Ocsv1Controller
Open, Needs TriagePublic
Actions

Description

Having mulled it over for a while, i believe the proposal below represents something which would function well with how the rest of OCS works, resulting in a low-impact but powerful extension to OCS. The proposal is a target for OCS 1.7, and its implementation in the ocs controller will allow us to test backwards compatibility with existing implementations (e.g. older installations of KDE software), while pushing for adding the new abilities we need in the future. A similar implementation will be made in libAttica and in KNewStuffCore, with the functionality employed for the KNS abilities of both Discover and Peruse.

The following text represents the proposal itself, and in part builds conceptually on the tagging support already found in ocs-fileserver:

Proposal for tagging support in OCS

Summary:
Add an element "tags" for PERSON, CONTENT and CONTENT download items (as downloadtags1, downloadtags2 etc).

Arguments for inclusion:
This is a low-impact addition of a method by which content type specific meta information can be added to various content items, without unnecessarily polluting the API with type specific details (such as concepts like sets, series, multi-resolution support, appstream IDs and the like, which only really make sense for e.g. training data (sets), books (series), wallpapers (wallpaper packs) or application bundles (appstream IDs). Many other uses might also be discovered, but these alone mean that it would be a worthy addition to the API.

Conceptual details:

Added on getters, setters and lists for person, content and content download items
Comma separated list of strings (both returned data and search arguments)
Namespacing suggested done with ## (see examples below)
Explicitly not using extended attributes for PERSON for tags, as this is supposed to be used for content item specific data storage (which is conceptually different to tags)

Additions to API documentation (and consequently API):

PERSON
search
URL Arguments: tags - string separated list of tags, match only full tag strings (no substring matching)

get
(no new URL arguments)

edit
POST Arguments: tags - string separated list of tags

Example (only showing new data and location in existing structure), same for both list and get:

<ocs>
 <data>
  <content>
   <tags>badge##kde</tags>
  </content>
 <data>
</ocs>

CONTENT
list
URL Arguments: tags - string separated list of tags, match only full tag strings (no substring matching). Match both in content and in downloads.

get
(no new URL arguments)

add,edit
POST Arguments: tags - string separated list of tags

Example (only showing new data and location in existing structure):

<ocs>
 <data>
  <content>
   <tags>set##contentid=11121,set##contentid=11120</tags>
   <downloadtags1>resolution##800x600,resolution##2560x1440</downloadtags1>
  </content>
 <data>
</ocs>

Non-exhaustive sample data for specific tags:

person: