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.
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) 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>
