Hello Sebastian, unfortunately my free time is very limited :(
On Fri, 5 Mar 2021 at 02:43, [email protected] <[email protected]> wrote: > As tried out in https://github.com/apache/openmeetings/pull/135 > => There are a lot of methods in those interfaces. Most of them have > little to do with handling streams or Kurento. > yes, by introducing such interface(s) you make yourself to copy/paste almost all contents of classes you would like to generalize > > I would suggest we refactor first a few things, and then introduce the > interfaces after: > > 1. Move static methods out of those classes into Util classes > 2. Move methods like StreamProcessor.hasRightsToShare, > streamProcessor.getBySid and other methods that do only rely on class > Client.java and ClientManager. Those methods should simply go into > ClientManager. > 3. Refactor so that "facade" methods like StreamProcessor.isRecording > - which simply could call a (new) method in kHandler.isRecording - so that > they call the right place right away > > So the idea would be that: > 1. StreamHandler holds the list of KStreams and makes operations to > get/add/remove those > 2. KurentoHandler holds the list of KRoom and makes operations to > get/add/remove those (+ holds the reference to the KurentoClient) > All above is not required for phase0/phase1 all you need for these phases is to add reference to KurentoClient to KStream (and use it for this particular MediaPipeline) I would like to suggest you to start implement your alternative clustering this way you will see what are the "generalisation points" and only then made any changed to current implementations And the very first thing I would do is to invent the way to plug-in new implementation into current code a quick search pointed me to @Primary Spring annotation which might help (and this also requires zero changes to OM code ...) > After that we can discuss the next steps. I think there will be still more > to do before introducing Interfaces. > > But I think having those classes being clear on their purpose and moving > methods unrelated to streams/Kurento out of them will make it a lot easier > - Easier to add new behaviour, Interfaces but also to make it easier to > concentrate when adding new behaviour to not look at a lot of > methods/functionality unrelated to handling streams/Kurento. > > I would make a new PR based on master for above. > > Thanks > Seb > > Sebastian Wagner > Director Arrakeen Solutions, OM-Hosting.com > http://arrakeen-solutions.co.nz/ > https://om-hosting.com - Cloud & Server Hosting for HTML5 > Video-Conferencing OpenMeetings > > <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> > <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> > -- Best regards, Maxim
