Design and requirements (old) #1

New Issue

jackhadrill · 2020-09-11T17:00:30Z

jackhadrill commented

2020-09-11 17:00:30 +00:00

I propose a very simple web application where users can either:

Create a room with a link to a H.264 encoded MP4 (something Video.js supports)
Join an existing room from a dropdown menu.

Requirements

User must be able to create a room with the following, mandatory arguments:
- username
- room name
- link to H.264 encoded MP4
User must be able to join a room with the following, mandatory arguments:
- username
- room name
User must be able to play, pause and seek the provided video.
User must be able to receive a list of users in the room.
User must be able to publish a "play position" and "play/pause state" to the room.
User must be able to retrieve the "play position" and "play/pause state" of all users in the room.
User must be able to follow another user's "play state".
User must be able to sync their "play position" to another user's "play position".

Technology stack

Redis - We need somewhere to store the data, but don't want disk writes. All the data will just be ephemeral (not persistent), so no need to trash the disk.
Flask - This is simple enough. Just need a couple of endpoints.
Video.js - It works nicely and exposes a more consistent API between browsers for video control.
HTTP - Videos will be served over HTTP rather than WebRTC, RTMP etc.
REST - all comms will be done over HTTP REST so that if @51m0n wants to make a MPC plugin it should be nice and easy.

Design decisions

Each will have two UUIDs generated.
- The first UUID will be used to identify the user during each HTTP POST request to the server. This is "private" to the user.
- The second UUID will be used to identify the user amongst all the other users. This is "public".
No attempts will be made to "secure" the application beyond the use of two UUIDs with different visibilities. Life's too short.
AJAX will be used in lieu of websockets for the initial prototype.

I propose a very simple web application where users can either: * Create a room with a link to a H.264 encoded MP4 (something [Video.js](https://github.com/videojs/video.js) supports) * Join an existing room from a dropdown menu. # Requirements * User must be able to create a room with the following, mandatory arguments: * username * room name * link to H.264 encoded MP4 * User must be able to join a room with the following, mandatory arguments: * username * room name * User must be able to play, pause and seek the provided video. * User must be able to receive a list of users in the room. * User must be able to publish a "play position" and "play/pause state" to the room. * User must be able to retrieve the "play position" and "play/pause state" of all users in the room. * User must be able to follow another user's "play state". * User must be able to sync their "play position" to another user's "play position". # Technology stack * Redis - We need somewhere to store the data, but don't want disk writes. All the data will just be ephemeral (not persistent), so no need to trash the disk. * Flask - This is simple enough. Just need a couple of endpoints. * [Video.js](https://github.com/videojs/video.js) - It works nicely and exposes a more consistent API between browsers for video control. * HTTP - Videos will be served over HTTP rather than WebRTC, RTMP etc. * REST - all comms will be done over HTTP REST so that if @51m0n wants to make a MPC plugin it should be nice and easy. # Design decisions * Each will have two UUIDs generated. * The first UUID will be used to identify the user during each HTTP POST request to the server. This is "private" to the user. * The second UUID will be used to identify the user amongst all the other users. This is "public". * No attempts will be made to "secure" the application beyond the use of two UUIDs with different visibilities. Life's too short. * AJAX will be used in lieu of websockets for the initial prototype.

jackhadrill changed title from ~~Design and requirements~~ to Design and requirements (old)

2020-09-21 17:17:19 +00:00

jackhadrill closed this issue

2020-09-21 21:23:32 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TerribleCodeClub/VCinema#1