A mopidy web client and api stack intended for a user request based music system. Will include a karma and user management system to help mitigate spam requests.
MIT License
1
stars
0
forks
source link
Current Song + Spam + Upvote + Downvote tracking #60
One part of this service that i know we talked about but never made it into the diagram was that there should be some way of marking which song is playing - we will need to track which users have made upvotes, downvotes, or spam notices for this song as well as be able to have a client api endpoint that gets the currently playing song. Because of that, to complete the Service we need to add a model called CurrentSong which will only ever have 1 row at a time. The model should have a 1 - 1 relationship with a song. We will also need to add models for upvote, downvote, and SpamReport. Each of these tables simply takes a user (and of course it's own id). When a song is playing, if a user upvotes/downvotes/reports spam we'd check the database to see if the user exists in the respective table (if they do we do nothing) if they do not, then we add them to the table and modify the song requestor's karma value. Then at the end of the song, the service should have an api endpoint to clear all three of the tables, and remove the song currently in the CurrentSong table.
One part of this service that i know we talked about but never made it into the diagram was that there should be some way of marking which song is playing - we will need to track which users have made upvotes, downvotes, or spam notices for this song as well as be able to have a client api endpoint that gets the currently playing song. Because of that, to complete the Service we need to add a model called CurrentSong which will only ever have 1 row at a time. The model should have a 1 - 1 relationship with a song. We will also need to add models for upvote, downvote, and SpamReport. Each of these tables simply takes a user (and of course it's own id). When a song is playing, if a user upvotes/downvotes/reports spam we'd check the database to see if the user exists in the respective table (if they do we do nothing) if they do not, then we add them to the table and modify the song requestor's karma value. Then at the end of the song, the service should have an api endpoint to clear all three of the tables, and remove the song currently in the CurrentSong table.