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

I want to add server side event listeners #22

Open
slifty opened this issue Nov 15, 2018 · 0 comments
Open

I want to add server side event listeners #22

slifty opened this issue Nov 15, 2018 · 0 comments

Comments

@slifty
Copy link
Owner

slifty commented Nov 15, 2018

Right now Opened Captions essentially functions as a proxy for a caption stream. It listens to a stream, and broadcasts that stream so that a socket-io client can connect and process.

This makes sense if your application is primarily client facing (you would have to use the socketio client in the browser application no matter how you slice it). If you want the server to be able to handle opened captions signals, however, this becomes a somewhat less intuitive model.

I see two options:

  1. Make it possible to register handlers directly with Opened Captions

  2. Stick with the existing model of requiring folks to import a socket.io-client (server side code establishes a connection to itself using the socket.io-client library)?

The case for option 2

There is potential value of sticking with (2), particularly when it comes to leveraging built in functionality around event filtering and management.

For instance, when we eventually add in things like having a single server handle multiple channels, socket.io would make it very straightforward to subscribe just to the channels you want to watch for; if we build a direct mechanism for responding to content we would either lose that filtering ability or we would have to rebuild it.

The case for option 1

On the flip side, option 1 does not prevent a user from still leveraging option 2 if they want to leverage socket.io capabilities. For folks who simply want to tap into the raw stream and are OK doing their own filtering it might be nice to not have to use an entire separate library to access events that are already being triggered.

Regardless of which path we decide to go, this should be better documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant