New data endpoint for dynamic liquidsoap config creation - #232
Conversation
Extending schedule endpoints to support week query param
…k (no changes required from App side)
6e22086 to
15818cd
Compare
5c011b2 to
15818cd
Compare
There was a problem hiding this comment.
Two questions quickly that I have about the overall picture.
- What's the reason to have 2 separate tpl's and functions (one for init, and one for the schedule)? Is it because of schedule changes without show addition/removal are lightweight this way?
- Did you think about creating a Schedule class for the Liquidsoap things? Those global environment.filters are a bit weird. And also I would say, I think the file name should reflect something ore generic like
schedule.pyand then we can create the LiquidsoapSchedule class or whatever.
|
Thanks for the comments @pvj !
I thought it would be better to handle them separately, because they have a different purpose.
A really good idea, generalization is always welcome! |
pvj
left a comment
There was a problem hiding this comment.
API calls look good, code is good too so I think we can move forward with this. Thanks!!
| " pm.expect(shows).to.be.an(\"array\")\r", | ||
| " shows.forEach(function(show) {\r", | ||
| " pm.expect(show).to.be.an(\"object\")\r", | ||
| " pm.expect(show.items).to.be.an(\"array\")\r", |
| init.daemon.pidfile.path.set("/var/azuracast/stations/lahmacun_radio/config/liquidsoap.pid") | ||
|
|
||
| log.stdout.set(true) | ||
| log.file.set(false) | ||
|
|
||
| settings.server.log.level.set(10) | ||
|
|
||
| settings.server.socket.set(true) | ||
| settings.server.socket.permissions.set(0o660) | ||
| settings.server.socket.path.set("/var/azuracast/stations/lahmacun_radio/config/liquidsoap.sock") | ||
|
|
||
| settings.harbor.bind_addrs.set(["0.0.0.0"]) | ||
|
|
||
| settings.tag.encodings.set(["UTF-8","ISO-8859-1"]) | ||
| settings.encoder.metadata.export.set(["artist","title","album","song"]) | ||
|
|
There was a problem hiding this comment.
Just thinking out loud, maybe some of these variables could be stored in config so it is easier to change settings.
It is a very minor case nothing serious as we don't really touch them
There was a problem hiding this comment.
I would leave this as it is now, but I agree that this should be configurable in the future.
/## Why make changes? State your reason
From programming point of view we're planning to extend our schedule for quite a long time, although the current design is not capable to return different weekly schedules.
As part of this PR my aim is to introduce
weekparameters for thescheduleendpoints with a default value of 1, in order to remain compatible with the current frontend / mobile application implementation.The schedule change will let us handle biweekly and monthly shows properly, and give us a bunch of time slots for possible new show ideas, but it will impact the usage of our Liquidsoap custom configuration as well, that will be handled in a much more flexible way.
What has changed? Describe your work
The following endpoints were extended with an additional
weekparameter:/show/all_schedule: used by the frontend/show/schedule: used by the mobile application/show/schedule_by: not used by anyone, just aligned with the other changesA new data endpoint (
/data/weekly_schedule) is also created, it generates the custom Liquidsoap configuration script. The script has two dynamic parts: the playlists' initialization and their scheduling.The new endpoint is generating this file from the current state of the Arcsi DB. There are 3 template files, one for the initialization, one for the scheduling and another with the static part of the script. The shows are used for templating the first two code snippets and they are inserted into the boilerplate file at the following lines: (initialization and scheduling).
It also has a
weekparameter but by default it returns the actual week's data.Added
LIQUIDSOAP_VERSIONvariable intoconfig.template.py, with the help of this the possible future Liquidsoap syntax changes can be tracked.How to review? Add scenarios or information on the output
The PR is deployed to the dev server, the new and modified endpoints can be easily reviewed there.
Notes. Share the github issue link, source link, or anything else
Another PR is expected to kick-off the multi week migration, there are two possible solution for this:
Show.weekInt field into an array orShow.weekandShow.frequency