Ok, there is a real example. We are going to implement ip video cameras integration into Openmeetings rooms, but most of all users don't need this feature at all. I suppose plugins API is not so complexity as it looks like. We should implement only features from the next list:
1. (Un)installing mechanism. 2. Plugins initialization when Openmeetings has been loaded. 3. Adding new menuitems into main and room menus feature. 4. Opening custom UI in main Openmeetings UI as <div> (Openmeetings logo, caption, menu and custom content). 5. Creating custom widgets feature In my imagination a plugin is only a bundle of some classes (maybe contained in a single jar). Openmeetings should notify plugins about events by calling their methods and plugins could call Openmeetings methods (not remote) too. 2013/5/30 [email protected] <[email protected]> > I think what you might initially meant was more like a plugin loader > mechanism on top of SOAP/REST. > > So those example with CMS integration do not fit from my point of view. > Cause that is actually the perfect use case for the SOAP/REST integration. > > So any kind of integration where you want to bring OpenMeetings > functionality in a 3th party application => SOAP / REST is perfect. > > But the other way round: If you want to bring 3th party functionality in > OpenMeetings, that is a use case where currently you permanently have to > change code in OpenMeetings. > Example would be: > - Somebody wants to code a new room type > - Somebody wants to integrate Alfresco document management into the > FileExplorer (however there is a way to sync documents with SOAP/REST) > - integration of a SIP/PBX box into OpenMeetings > > The reason why this has been never done so far is because of its > complexity. The API that you would need to create to do that would be so > general that its almost like _anything_ is possible and using this API > would be almost as complex as writing native code for OpenMeetings. > > After all an additional plugin loader mechanism would be a benefit if > really somebody would use it. > Just because there is a single application, like for instance the Sip > Integration, I would not design an plugin API for that. > Cause that API is likely to be specific to Sip Integration, nothing else > could use or have a benefit from it. > > Can you give example of a real use-case and what kind of API methods such a > plugin mechanism that you have in mind would have ? > > Thanks, > Sebastian > > > > 2013/5/30 [email protected] <[email protected]> > > > Hi Artyom, > > > > if somebody wants to get statistics of rooms he would be interested in > > those logging tables in the database. > > Why would anybody try to extend UI functionality. That seems to me making > > this task rather more complex then easy. > > > > Sebastian > > Am 30.05.2013 08:57 schrieb "Artyom Horuzhenko" <[email protected]>: > > > > Unfortunately Soap or Rest API method are not enough. They don't allow > >> extending UI and requires running Openmeetings extension as another > >> application. Remote methods are good in integration with other software > >> such as Moodle or Joomla, but can't help to improve Openmeetings. Lets > >> have > >> a look at this example. A developer wants to create a plugin which > allows > >> to view users visiting statistics: who and when enters the conference. > All > >> statistics would be available in administration menu. But for some > reason > >> he doesn't want to commit (or send us as patch) his changes to our > >> repository. Of cause, the developer could implement getting statistics > by > >> using remote methods, but now there are no way to add view statistics UI > >> without changing Openmeetings code directly. > >> > >> > >> 2013/5/30 [email protected] <[email protected]> > >> > >> > There is a Soap and Rest API that can do what you describe. > >> > > >> > Sebastian > >> > Am 29.05.2013 23:13 schrieb "Artyom Horuzhenko" <[email protected]>: > >> > > >> > > Hello all, > >> > > > >> > > I have an idea about improving Openmeetings. It would be better if > >> > > Openmeetings has plugins API like browsers. There are a lot of > >> reasons of > >> > > that: > >> > > > >> > > 1. Now we have a some extensions code which contained directly in > >> > > Openmeetings (for example, red5sip). This fact is one of the causes > of > >> > some > >> > > bugs and complicated architecture. Plugins API will allow us to move > >> all > >> > > red5sip code into the plugin. > >> > > > >> > > 2. We will be allowed to use GPL (or other incompatible licenses) > >> code as > >> > > plugins in Openmeetings. > >> > > > >> > > 3. Easy and documented API will involve new developers into creating > >> > > plugins for their and public uses. > >> > > > >> > > 4. Integration with various CMS-es will be improved by ability of > >> > extending > >> > > Openmeetings UI. > >> > > > >> > > > >> > > In my opinion plugins API should allow developers: > >> > > > >> > > 1. Do various operations (add, remove, change etc) with users, > rooms, > >> > > organizations > >> > > > >> > > 2. Subscribe for various events, such us "user entered the room" > >> > > > >> > > 3. Extend UI by adding new menu items (at least) > >> > > > >> > > 4. Read/write various settings keys > >> > > > >> > > I would mind discussing this new feature. Is there anybody who has > any > >> > > commets, notes or another opinion? > >> > > > >> > > >> > > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] >
