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]
