Artyom, noone will argue with good and documented API, yet there are many other directions ahead e.g. HTML5 challenge.
Do you have any particular particular task in mind where these plug-ins would be immediately useful? -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://dataved.ru/ +7 916 562 8095 On Fri, May 31, 2013 at 9:52 AM, Artyom Horuzhenko <[email protected]> wrote: > 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] >>
