My plan is to extend the HTTP API [1] with an event stream [2] that can be accessed via https-with-a-session-cookie or http-over-Unix-domain-socket. It could be used by browser-based Javascript, mobile clients, and automated event subscribers. One could write a subscriber that launches a subprocess or runs scripts in-process. I think there are a few advantages over doing this directly from the main process:
* it keeps the main process logic minimal. This API is needed anyway to make a good web interface.
* it's the easiest way to have nothing else run as the same Unix user as the main process. My design is similar to a DBMS in that that you should only ever be accessing Moonfire NVR's data through its interfaces (except for development or emergency maintenance purposes). Having a dedicated user helps enforce that.
* your script can run on a separate machine if desired
Also a couple disadvantages:
* two services to set up (main process + subscriber) instead of one.
* there's the possibility that an event happens while the main process is running but your subscriber is disconnected, so the event gets committed to the database but you never see it. The easiest thing to do is to accept skipping these (as would happen anyway if the main process is down). Or the main process could buffer events for a while. Or the watcher could have logic to "catch up" (which unfortunately means not only more complex logic but also keeping state somehow).
If you'd prefer another approach or want it sooner than I'm likely to implement it, please contribute! I have my priorities & design ideas, but if you chip in, you get a say in both. And I go pretty slowly on my own anyway, so if you're able, it's worth chipping in even if you agree with me about everything.
[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...
[2] https://github.com/scottlamb/moonfire-nvr/issues/40