Yes, I have: http://code.google.com/p/jain-sip/ But the main reason of rewriting red5sip as a plugin is a code which located directly in Openmeetings.
2013/5/31 Alexei Fedotov <[email protected]> > Oh, I see. Having most of red5sip functionality under APL would be > great achievement. You once mentioned you have found MIT-licensed SIP > stack, haven't you? > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Fri, May 31, 2013 at 3:29 PM, Artyom Horuzhenko <[email protected]> > wrote: > > I also would be glad to rewrite red5sip as a plugin and remove all > red5sip > > code from Openmeetings > > > > > > 2013/5/31 Alexei Fedotov <[email protected]> > > > >> Ok, I see you've mentioned IP camera integration task. > >> -- > >> With best regards / с наилучшими пожеланиями, > >> Alexei Fedotov / Алексей Федотов, > >> http://dataved.ru/ > >> +7 916 562 8095 > >> > >> > >> On Fri, May 31, 2013 at 3:26 PM, Alexei Fedotov > >> <[email protected]> wrote: > >> > 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] > >> >>> > >> >
