High level implementation

[benjaminkay93]

So the old roses graphics over on LA1TV, worked using WebSockets with an admin panel controlling a webpage, I'm putting this issue here to think around other options on how to do this conceptually.

Is a server running that the client view subscribes to and an admin panel that pushes state to the server what we want? How heavy do we want the middleware server to be? What do we use for controlling state? Can we take an approach where the components and admin panel are tide together?

[benjaminkay93]

One approach could be to treat it as a a single page app, and just have the admin and cg view tied together and served tied,

Another could be to have them completely detached, with a database in between to tie everything together.

[eol-account]

After rewriting a lot of the RosesCG backend this year, I would like to push for some central state manager, if not a database. Sockets are definitely much faster than the HTTP requests I replaced them with, the the Roses graphics had a lot of data that just sort of "appeared" at run time, making tracking down bugs difficult.

Plus, some bugs were due to copy-pasted code subscribing to the wrong socket event, so I would be nice to have some automagic way to assign a socket/http endpoint to each component loaded into the system that the graphics developer can just read from/write to. Probably just wishful thinking though, and would probably make the internals of the system too complicated.

[benjaminkay93]

its something we really need to think about, i think this is gonna be the biggest inital problem we come across in this project and im not sure of the answer, we could tightly couple things to data drive components through something like a graphql api and just having a small server running to handle the data pasage with push events.

completely agree on the automagic, it should 'just work' out the box, and shouldn't have any direct wiring that a user could interact with, or have to add things themselves when making new components

[eol-account]

I have an idea how to handle the "automagic" part, I might be getting a little too into the details but if it's worth discussing further I'll go ahead and open an issue to work out the details.

Basic idea:

• Each component comes in however many parts (admin panel/client object/whatever).
• A module loader keeps track of all the classes associated with a particular component/module.
• Each instance of a component client/admin panel is required to be given a "group name".
• Multiple instances of the same client component can be controlled by one admin controller if they have the same group name.
• Or we take the chance that components aren't going to be reused one the same page and force unique names.
• A combination of a hash of the class name for each component + the group name is used to uniquely identify a controller->data->client relationship in terms of the data needing to pass between them.
• Issue here is that two components could not share the same name or they would produce the same hash.
• The "CG/client" and "admin" windows would then have a loader that scans for components on the page (allowing components to be inserted in pretty much any way, as long as they exist when the page loads).
• The loader would generate a hash from the class name + group name (which should match the ones from the module loader).
• A central data store could then map client hashes and admin hashes to the data they are accessing.
• A blank group name would still automatically provide a relationship, unless multiple instances of the same component without names exist. So group names could be considered an "advanced" feature.
• Only issue is... getting the "class name" in JS can be a little messy. Also, I don't know how well this would work if anyone puts their component through an uglifier.

If we do allow multiple clients to share one admin controller, any external data sources (e.g. Scores from RosesLive) would need to be handled either in the admin panel or a central data store else we may get collisions. Probably best in a data store, as the admin window may not necessarily be open.

That's a lot more detail than I was wanting to get into, feel free to banish me to another issue :P

[benjaminkay93]

Be gone with ye!

Nah its all good, ill have my fair share of brain dumps and its good food for thought. We should be careful at this point not to go to in depth but I would never want to discourage someone from putting ideas down 😄

Its a really good idea though, let's see where we go with ideas and bare this in mind as we go!

[stephenrob]

I've been doing a lot recently with Laravel and VueJS on the frontend. Have a look at the Laravel Mix package for how it does some fancy things to abstract away installing NPM packages etc for managing webpack. (Never thought using webpack could be soo simple :) )

[benjaminkay93]

webpack is easy, just requires a few hours of youtube videos :') Personally, I want to avoid mixing languages as it just increases the barrier to entry and adds complexity where it's not needed, open for the debate ofc though:)

[eol-account]

Another idea from Roses graphics experience:
I think it would be useful to ship a bunch of built-in "data types" like a simple counter (e.g. for football scores). But where more complicated processing needs to happen (e.g. for the progress bar for the Roses scores/ splits for swimming/ fancy game show graphics), stations would be able to add their own "data type"?

So when defining your graphics you could say "this value is a counter known by this name" then on the cg and admin panels say "this displays the value of the counter, this adds one, this takes one away".

I'm picturing the data types as living in the data storage area of the framework, whatever that may be. Rather than having the admin panel/cg responsible for calculating these things + cluttering up the code for those.

[benjaminkay93]

yeah im in strong agreement the actual views should be thin data driven views, that have their own ethemeral existance that could be completely detached, that they both read from/to