Alexei, unfortunately using Jain SIP won't allow us to change license in red5sip. Red5sip also contains nellymoser audio codec implementation licensed under gpl and we have no alternatives.
2013/10/31 Alexei Fedotov <[email protected]> > Code convention discussions should generally involve much more flame. :-) > > IMHO the worst thing about Asterisk integration is APL/GPL license > incompatibility. I wonder if one can made red5sip available at apache > Jain SIP (http://dev.telestax.com/jain-sip/) is public domain, yet it > is unknown if it is good enough. > > Compared to licenses table names are minor issue (and likely at least > one of them are replaced with Asterisk API), and are good for those > who want a soft start as an openmeetings developer. > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > [1] Start using Apache Openmeetings today, http://openmeetings.apache.org/ > [2] Join Alexei Fedotov @linkedin, http://ru.linkedin.com/in/dataved/ > [3] Join Alexei Fedotov @facebook, http://www.facebook.com/openmeetings > > > On Tue, Oct 30, 2012 at 5:08 PM, [email protected] > <[email protected]> wrote: > > I would like to discuss some design guidelines for OpenMeetings. > > The goal should be that we all apply those guidelines, not because we > have > > to but because we share the same ideas :) > > > > *1. No db related actions in sync methods* > > A sync method is for example > > ScopeApplicationAdapter::syncMessageToCurrentScope > > Such a message means, client A wants to send a message to client B. For > > example "changeSlideOnWhiteboard". > > Actually the best would be if the clients would communicate directly > > without proxying every message through Red5. However Flash can't P2P (or > at > > least there is no public solution for that). > > So we are forced to proxy all data through Red5. We may verify some > > authentication data by using the session data for each connection on the > > server side, however we don't do any kind of database action in those > > methods cause actually it should be as fast as possible. > > > > Exception from this pattern might exist. For example you could start in > the > > sync method a separated Thread so that DB related stuff is handled > > asynchronous. > > However, any kind of exception from this guideline should be discussed > and > > verified based on consensus with the rest of the community. > > > > *2. There is no way that the entire db cache will be disabled because of > > feature xyz* > > One integral part of any ORM is caching the DB results to speed up > things. > > Therefore if anybody wants to optimize OpenMeetings he is likely to play > > around with cache sizes. > > There is no chance that a single feature that is needed for any component > > of the application will disable the db-cache entirely. > > > > Exception from this pattern might exist. For example you can use: > > <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> > > And mark exceptional one or more table to be not cached. > > However, any kind of exception from this guideline should be discussed > and > > verified based on consensus with the rest of the community. > > > > *3. If anybody communicates with an OpenMeetings instance database this > > should happen via a defined API* > > Because we are using a database cache and also because we don't want to > end > > up in a situation where any kind of 3rd party application writes data to > > our database we want the data to be transferred to OpenMeetings via a > > defined API, not just written to its database! There are many reasons why > > having this abstraction layer is useful, for example if we want to change > > the database schema, instead of changing 10 applications that write > > anything to the database we only change a single one but the API stays > the > > same. > > This means also if multiple instances of OpenMeetings communicate with > each > > other, they communicate via a defined API, they do not just write to each > > others database. > > > > Exception from this pattern might exist. One exception will be for > example > > the Asterisk integration. Cause it will only use 3 tables and there are > > currently no resources available to change this. > > However, any kind of exception from this guideline should be discussed > and > > verified based on consensus with the rest of the community. > > > > Your feedback is welcome :) > > > > Sebastian > > > > -- > > Sebastian Wagner > > https://twitter.com/#!/dead_lock > > http://www.webbase-design.de > > http://www.wagner-sebastian.com > > [email protected] >
