There is a “highlighting language” for each source file. Per default, this is 'python' as the majority of files will have to highlight Python snippets, but the doc-wide default can be set with the highlight_language config value.
2021-03-18 07753, 2021
alastairp
For documents that have to show snippets in different languages, there’s also a code-block directive that is given the highlighting language directly:
2021-03-18 07719, 2021
alastairp
right. so my intuition is that we're using :: (for example in validate-token) and it's highlighting it as a python doct
2021-03-18 07720, 2021
alastairp
dict
2021-03-18 07740, 2021
alastairp
but in the case where we use code-block, it's rendering it the same, but highlighting with json instead of python
2021-03-18 07746, 2021
_lucifer
makes sense
2021-03-18 07758, 2021
alastairp
let's use code-block:: json
2021-03-18 07701, 2021
alastairp
it's nice and explicit
2021-03-18 07703, 2021
_lucifer
👍
2021-03-18 07736, 2021
_lucifer
let's merge this PR then, I'll include the code-block changes in my PR to add the missing api socs
alastairp, another thought that came to my mind recently. reviewing code is as much work as writing code so it would be nice if automatically added `Reviewed By` to commit messages on a merge according to users who reviewed the PR.
ListenBrainz uses collaborative filtering to generate recording recommendations. These are further to processed to generate playlists for users. These api endpoints allow to fetch the actual recordings programmatically.
2021-03-18 07740, 2021
_lucifer
ruaok: how does that sound for description of get_recommendations edpoint?
2021-03-18 07735, 2021
ruaok
Let me look when we return from lunch, _lucifer
2021-03-18 07746, 2021
_lucifer
👍
2021-03-18 07707, 2021
reosarevok
ruaok: the latest "Re: Please verify your email address" is actually an answer to you (since you might not think of checking it)
"ListenBrainz uses collaborative filtering to generate recording recommendations, which may be further processed to generate playlists for users. This api endpoints allow to fetch the raw collaborative filtered recording IDs."
2021-03-18 07700, 2021
ruaok
it how I would say it.
2021-03-18 07719, 2021
_lucifer
sounds good, i'll use that. thanks :D
2021-03-18 07747, 2021
ruaok
np.
2021-03-18 07712, 2021
_lucifer
when do we have the meeting for Oauth discussion?
2021-03-18 07728, 2021
dpmittal_ is now known as dpmittal
2021-03-18 07746, 2021
alastairp
hi dpmittal. I merged your PRs, thank you!
2021-03-18 07732, 2021
ruaok
_lucifer: ready for some task planning for the next few weeks?
2021-03-18 07746, 2021
_lucifer
yup :)
2021-03-18 07730, 2021
dpmittal
hi alastairp Yea I saw that, Thanks a lot for reviewing and merging the changes :D Actually, by the time I had a look at your suggestions you had already committed them, Apologies for that
2021-03-18 07744, 2021
ruaok
ok, we see three distinct projects headed your way.
2021-03-18 07756, 2021
ruaok
1. YouTube player reimplemention
2021-03-18 07700, 2021
ruaok
2. AB work.
2021-03-18 07710, 2021
ruaok
3. MetaBrainz OAuth/user account migration.
2021-03-18 07735, 2021
ruaok
we hope that we can do the youtube stuff in 2 weeks time and then 2 weeks for AB.
2021-03-18 07753, 2021
ruaok
alastair will plan out the AB work and will have more details once you finish up the YT work stuff.
2021-03-18 07715, 2021
ruaok
in the meantime alastairp and I will meet next week (and likely the week thereafter) to work out the details of the OAuth spec.
2021-03-18 07716, 2021
shivam-kapila
I just noticed we now have 10 sponsors on GitHub. Yay!!
Mr_Monkey: it wouldn't allow me to make the doc public without revoking my edit access.
2021-03-18 07722, 2021
ruaok
can you please give edit access to _lucifer, alastairp and myself.
2021-03-18 07723, 2021
ruaok
?
2021-03-18 07757, 2021
Mr_Monkey
I think it was just you missing ruaok :) Should be good now
2021-03-18 07716, 2021
ruaok
thx
2021-03-18 07722, 2021
ruaok
_lucifer: the first point of work will be to review the doc and to propose a new schema for tracking the player services/user account.
2021-03-18 07735, 2021
ruaok
then update the endpoints that are proposed in the doc.
2021-03-18 07752, 2021
ruaok
there are going to be a lot of open question that we simple don't have an answer for.
2021-03-18 07707, 2021
_lucifer
makes sense
2021-03-18 07715, 2021
ruaok
if you find questions like these, add a section to the doc with open questions and ping Mr_Monkey/me on them.
2021-03-18 07704, 2021
ruaok
now, your work should stop after YT and Spotify are implemented.
2021-03-18 07720, 2021
ruaok
we should open up deezer and apple music as GSoC projects for LB.
2021-03-18 07731, 2021
ruaok
we think that one service would make a decent GSoC project.
2021-03-18 07750, 2021
ruaok
which gives a we bit more than a week to update the LB ideas page.
2021-03-18 07733, 2021
Mr_Monkey
I want to point out that while the document we're looking at is about server-side auth for music services, adding other players on the front-end will most likely not require server-side auth (at least for those music services I looked at)
2021-03-18 07732, 2021
Mr_Monkey
Now if we want to do more than playing music through the front-end on those other services (for example getting users' listening activity), we *will* need server-side auth as a separate matter
2021-03-18 07729, 2021
_lucifer
cool, i'll start work on this asap.
2021-03-18 07702, 2021
sumedh joined the channel
2021-03-18 07752, 2021
ruaok
_lucifer: I'm adding the section "open tasks" at the bottom of the doc. you should deffo work on those tasks before diving in too deep.
from a dev using our API: "The lookup / search work really well, are a breeze to use and documentation is really good. As a music lover I really appreciate what you're doing."
