You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Make it possible to register handlers directly with Opened Captions
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.
The text was updated successfully, but these errors were encountered:
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:
Make it possible to register handlers directly with Opened Captions
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.
The text was updated successfully, but these errors were encountered: