Brainstorming Radios

gcrk

We noted that before we can properly implement endpoints for APIv2 for the radios, we probably need to have some proper planning of the feature. I am therefore starting to collect information I find while investigating the topic.

At first a class diagram for the radios we have:

[upl-image-preview url=https://forum.funkwhale.audio/assets/files/2023-07-05/1688550360-756732-classes-radios.png]

This was generated using poetry run pyreverse -o png -p radios funkwhale_api/radios/radios.py

Please note that all the different radios are inheriting from the SimpleRadio and the SessionRadio. A first good step might be to unify SimpleRadio and SessionRadio into one class called BaseRadio which is providing the interface for all the radios.

gcrk

The main interface for our radios is the following:

SimpleRadio:
  clean(instance : ?) -> ?
  pick(choices : List[int], previous_choices : Optional[List[int]]) -> int
  pick_many(choices : List[int], quantity : int) -> List[int]
  weighed_pick(choices : List[Tuple[int, int]], previous_choices : Optional[List[int]]) -> List[int] 

SessionRadio:
  start_session(user) -> Session
  get_queryset()
  get_queryset_kwargs()
  get_choices()
  filter_queryset()
  filter_from_session()
  validate_session()

TBC

gcrk

Quoting @wvffle:

Start the session with POST /api/v1/radios/sessions/, the id is returned
Ask for a track with POST /api/v1/radios/tracks/ with the session field which contains a value of previous request's id
Ask for the track uploads with GET /api/v1/tracks/<track_id>/
Ask for the media and cover on the fly
go to point 2 when needed

petitminion

if I recall there was a confusio between CustomRadio and CustomMultiple.

CustomRadio is use to generate User radios that are saved in to db with their config. It uses filters to validate the config before saving it into db.
CustomMultiple is used to generate radio from multiple related object using a config and filters.py (like CustomRadio does). But the config is generated by the front automatically and isn't saved into db.

I don't think changing the whole logic to only use CustomMultiple and filter is the best approach because config is build to work with filter and related object. So it would be not efficient for ramdom radio, library radio, less listened.
But I think we need to change the name of the radio to make this more clear, and even add a description of how they work:

CustomRadio could become CustomUserRadio with Used to generate User generated radios. The user add filter parameters, that are send in the config parameter. The filters validated the config before its saved into db
CustomMultiple could become DynamicFilteredRadion with Use a frontend generated config. Config is not saved into database but is validated by filters.py

wvffle

I have no idea how it works now, but are we eager loading all artist and album info when fetching radio tracks?

The info that frontend needs is:

Track id
Artist name
Artist id (for url)
Album name
Album id (for url)
Uploads
Album / Artist / Track cover art (I'd suggest to use a url like /api/v2/coverart/track/<track_id> that automatically selects the cover art based on what's available in order: track, album, artist)

So maybe it'd be better to store the album/artist list in the radio object and return them when we start the radio session?
We could save that info in the frontend and then just reference it by id without needing to ask the database each time?

petitminion

wvffle Radio are generated on the flow,dynamically. Results change depending of the db states and this mr https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/2430 worksquit well to avoid hitting db I think.

We could change what track data is send to save a little bit of space indeed. I can write a MR for this when we merge https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/2430 and finish to agreed if we send a radiosessiontrack or directly a list of tracks.