The main reason of plugins is using 3th party code in Openmeetings without changing it. I'm worried about having some extensions code in Openmeetings. This fact increases the risk of potential bugs and complicates architecture.
2013/5/30 [email protected] <[email protected]> > That is basically all possible but as long as you don't documentate a > really easy to use, but at least documented API for those who should use > this plugin loader mechanism I see no advantage. > I mean anybody that writes such a plugin will then end up in looking at > OpenMeetings source code to get his job done. > > So if we decide on doing a plugin I think at least a documentation about > what APIs the developer can use would be needed. > > Sebastian > > > 2013/5/30 Artyom Horuzhenko <[email protected]> > > > 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] > > > > > > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] >
