[FEAT]: Efficiency to send periodic real-time sensitive huge data (e.g. video, audio, multimedia)
dumblob opened this issue · 2 comments
Description
I have skimmed the example and I think it is a decent architecture. I wonder though whether the system is designed for high-throughput and modestly low-latency (in both directions) and could be thus used to stream real-time video to subscribers and vice versa (new video coming from subscribers and save it to HDD at the backend side).
Is this somehow possible? Or are there any known (i.e. "by design") bottle necks (e.g. due to compression, superfluous copying of data, synchronous messaging leading to random delays, ...)?
Additional Information
No response
I did my absolute best to only introduce flow logic bottlenecks as needed. When you write operators and trees, all it does is execute those operators in sequence and pass function outputs along, and otherwise you are the one enforcing data structures on that. Otherwise it will take care of promises/async for you and any node operations without additional flow logic run synchronously. Graph.ts has the core code here and it's as generalized as I could make it so you can extend the nodes or graphs to customize pluggable functionality.
For frontend/backend protocols you have access to all of the raw send/receive functions and otherwise I automated everything with a really basic object structure via the Services so different program instances know how to talk to each other generically to execute commands or even build whole programs out dynamically.
As far as examples go, give us a little more time to realize the docs here. We are working with HTIL at UA to produce educational tools and this is the base.
Oh yeah also we took full advantage of pass-by-reference objects in js so nothing is ever copied superfluously
Ok, that is good news. This is not urgent, so take your time - I was just pre-evaluating the capabilities of this library for one special project (which has low priority unfortunately). Therefore my weird question(s) 😉.
Btw. thanks a lot for the HTIL @ UA reference - my mind got almost blown away seeing what they/you do there (I saw only the published part, of course). Keep going!