[UI Logic] Persist Passive Signals

[Jason-KChen]

Why/What

• Once emotion detection is done. Please persist the signal via the API endpoint

Guideline

0. See generic code pointers for API call code pointers. Always check the status field
1. Invoke video/addPassiveQuestion with POST request to persist the point
2. Three parameters are needed, see following structure,

   {
   "videoID": "test",
   "timestamp": 122,
   "student_name": "tom"
   }

3. The return looks as follows,

   {
   "status": true
   }

4. Please be mindful about the frequency in which signals are being sent. How can I tell? If you notice that thousands of API calls were made in the background for a 2 second distressed face, then you are doing something wrong. From the infra perspective, the backend is not gauranteed to sustain such traffic pattern.
5. In addition, think about how signal should be represented. For example, if a distressed emotion was detection from timestamp 10 through 15. What is the expected result on the dashboard? The discrete timestamps [10-15] should have exactly 1 count in the graph? Or should there be more than 1 count? There is no perfect answer, your justification should be clear in your code/doc/comments.

p.s.: There are some more context about what I said above. Currently, the way we are illustrating signals, active or passive, is through a bar graph. The bar graph gives an idea on how many occurrences (y-axis) a timestamp (x-axis) has. X-axis is in continuous in the sense it covers the duration of the video. However, they are also discrete in the sense that each signal, passive or active, are currently stored and associated with a discrete timestamp (integer value). This is a valid and functional representation as of right now. If you believe that the continuous model (using non-discrete timestamps) to record passive signal is better, let me know. I encourage you to try to integrate the API endpoint first and base your argument on the actual workload, network traffic pattern, and rate limiting mechanism.

[github-actions[bot]]

👋 Before you start, read the following guideline\n

1. Generic code pointers in #59
2. Give your branch a short and meaningful name, pull request title should be the same as your branch name
3. Keep your pull request/commits small
4. While working on the same issue, it is okay to have multiple branches. Second feature should be branched off first feature if there is a dependency.
5. In the commit message, prefix the message with [#issueNumber] like [#1] easy referencing.
6. Once a pull request is opened, check the linter and the code you submitted (under changed files tab) to make sure everything is correct
7. After revision, please re-request review by clicking on the circle next to reviewer names
8. If the change has to do with UI, please include screenshots of the changed UI as part of the pull request
9. If your feature branch is stale, always rebase instead of merge.

[Jason-KChen]

@MrNickWan See above for passive endpoint format

[Yuliy97]

Transferring the issue to Nick.