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]
