The complete set of commands found in those files, though, is a small fraction of what the app can tell the core to do. There’s no such commands for playlist manipulation, for example, which is what I want to do.
Aha! says I, I can use Wireshark (which I’ve never touched before today) to capture the traffic from the app to the core and so reverse engineer the API.
However, I’m starting to wonder whether the app is actually using the published API. That is, can I discover a name like “com.roonlabs.playlist:2/delete_items” (analogous to the “com.roonlabs.transport:2/mute_all” in the above code snippet)? Or does clicking the button in the app go through a completely different mechanism?
Ah, yes, now I remember I saw that. But that API (as published) is incomplete. There could be many other endpoints for, say, controlling playlists. My question is: could that documentation be updated to include already-existing endpoints that the Roon app uses? or is playlist-manipulation done in some completely different way?
If there are undocumented endpoints, can they be discovered and used by “just plain programs”?
I just want to write a little Mac app that lets me say “move these 1 or more items from this playlist to that other playlist, and oh by the way, skip creating duplicates”. Is that possible? How hard would it be?
My guess is that the roon app doesn’t use the published api, but hard to be sure.
I’m not aware of anyone trying to reverse engineer what the roon apps do to speak to the core
I maintain a python library that uses the undocumented rest api that is used by the documented node api - so there was a little reverse engineering needed - but nothing like you’d need to do.
Using the published api is reasonably straightforward if it can do what you need, but, as you say, its functionality is limited.