Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
alxpettit opened this issue Sep 10, 2018 · 10 comments
Closed

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

alxpettit opened this issue Sep 10, 2018 · 10 comments
Labels
enhancement help wanted

Comments

@alxpettit
Copy link
Contributor

@alxpettit alxpettit commented Sep 10, 2018

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
Copy link
Contributor

@Et0h Et0h commented Dec 9, 2018

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.

@alxpettit
Copy link
Contributor Author

@alxpettit alxpettit commented Dec 9, 2018

I thought syncplay.lua was for VLC?

@Et0h
Copy link
Contributor

@Et0h Et0h commented Dec 9, 2018

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

@Et0h Et0h added the help wanted label Feb 1, 2019
@Et0h
Copy link
Contributor

@Et0h Et0h commented Feb 1, 2019

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.

@alxpettit
Copy link
Contributor Author

@alxpettit alxpettit commented Feb 3, 2019

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.

@alxpettit
Copy link
Contributor Author

@alxpettit alxpettit commented Feb 19, 2019

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.

@alxpettit
Copy link
Contributor Author

@alxpettit alxpettit commented Feb 19, 2019

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...)

@alxpettit
Copy link
Contributor Author

@alxpettit alxpettit commented Feb 27, 2019

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
Copy link
Contributor

@Uriziel Uriziel commented Mar 6, 2019

@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
Copy link
Contributor

@Et0h Et0h commented May 16, 2020

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.

@Et0h Et0h closed this as completed May 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement help wanted
Projects
None yet
Development

No branches or pull requests

4 participants