Feature request: generic event hook system (a la acpid)

[crabdancing]

So, the point of this suggestion is to cover as many use cases as possible to prevent feature creep in the base code and the amount of load on the base code devs, while still getting extra features that cover minority use cases.

In my case, I'm very interested in the potential of Syncplay for study groups. Khan Academy has a gamification system that lets you keep track of your study activity and rewards you with Meaningless Internet Points (TM), which are fun to receive, despite being mostly meaningless. :P

I saw that Khan Academy seems to have decent API documentation, which should be a breeze to use from Python -- so it totally has potential. A hook system would allow for these sorts of solutions to be built for all sorts of obscure needs. I'd be willing to develop the integration hooks myself if the hook system was easy enough to figure out! And of course release it under some FOSS license because I like FOSS. :3

Off the top of my head, the hook system could also be used for lots of other things as separate projects, including:

• Optional audio notifications of events (In several instances, I had accidentally pressed m in MPV previously, and wasn't aware someone had started the video)
• Optional toaster or other GUI notifications (In other instances, I had my whole pulseaudio system muted because I'm a dork, or was otherwise unable to hear laptop audio due to a glitch with my bluetooth headset -- so these notifications would be great for me)
• Integration with other learning platforms (e.g., Moodle)
• If some hacker somewhere wants to make their raspberry pi controlled coffee maker start brewing coffee whenever a video is queued, they can totally do it without forking the base code. (And catch-all for any other obscure scripting use case I'm not imagining.)

Let me know what you think!

[Et0h]

I like the idea of making Syncpplay more extensible in a way that avoids feature creep, but I don't see myself as having time to code such a thing in the foreseeable future.

For mpv users some things are possible at present via modification/extension of syncplay.lua as the mpv script can actually run Syncplay /commands and has access to notifications, etc. It is possible that more could be done in this regard to allow mpv scripts greater information and access.

[crabdancing]

I thought syncplay.lua was for VLC?

[Et0h]

@alxpettit Ah yes, I should have said syncplayintf.lua: https://github.com/Syncplay/syncplay/blob/master/resources/syncplayintf.lua

[Et0h]

We do not currently have any volunteers to work on this project, but if someone volunteers either to work on making Syncplay more extensible or specifically on adding Khan Academy support then please let me know. If nobody comes forwards then I will close the issue but add it to https://syncplay.pl/about/ideas/ as an idea that someone could help progress.

[crabdancing]

I volunteer! I don't have a lot of free time, but fortunately Python is the main language I like to code in, and I don't think I'm too rusty.

[crabdancing]

So, it's been awhile, and I'm going to finally start going through the code in my free time and see if I can figure out where the event hooks should be placed and how they should be implemented.

Another option is to use a plugin system for dynamically loading in Python code instead of calling external applications -- which is potentially a more polished way of doing it, but may make it more difficult for non-Python programmers to interact with the system. I'd like to make sure it's as useful to as many people as possible, and not just me. :P

Having a single program called whenever an event happens, and having the entire thing event-driven, seems like it ought to work for most use cases that I'm envisioning. If a user wanted multiple scripts for each, they could just use a switch case thingy. If they want to do it in Python, or Bash, or C++ -- it'll work just fine. The only requirement is that they understand how to parse the arguments.

So, the next question is how the arguments should be formatted. I'm tempted to do it with just a single JSON string, since Syncplay already handles JSON and it's a good way of unambiguously structuring nested data for when arbitrarily large amounts of contextual information are needed.

But on the other hand, if someone wants to make a handler in Bash, I suspect they're going to have a bad time trying to cope with JSON input.

[crabdancing]

Another concern is whether someone would want external code to continuously run in the background or not. Forcing an event-driven architecture on this implementation would mean that applications that might benefit from continuously running code inserted into Syncplay itself, would have a harder time.

For example... if I wanted to write a Syncplay app that did a lot of complex regex for some reason -- it would have to reload the interpreter executable, any libraries needed, and recompile the regex, every time it had to process something.

Which means that this application is only acceptable if this inefficiency won't affect too many use cases. (Of course, if they were desperate enough I suppose someone could write a two-part application with a "trigger script" that just got launched by the event hook system and then quickly passed the data straight to a server component over IPC and then exited...)

[crabdancing]

Um... not really getting a lot of feedback here. I guess I'll just start doing stuff and hope that it's actually compatible with what the community wants.

[Uriziel]

@alxpettit Hey. Sorry for not getting to you earlier. I don't think you have to worry about using json in bash scripts, as there's jq that can help handling it. And I think jsons would be the most readable solution here too.

As for the way you'd handle the event sourcing, I don't really have an opinion on that. IMO it's best if you just implemented your app in parallel and you'd see what works best.

A simple solution would be Twisted's plugin system

[Et0h]

If this is how Syncplay was coded from the start to use an event system then a lot of current Syncplay features could have been plugins, simplifying the main codebase. However, adding an event system at this stage could add complexity to Syncplay which could make it harder to maintain the codebase. I have now added your idea to https://syncplay.pl/about/ideas/ so that others can be informed by this discussion.