You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Alexei Fedotov <al...@gmail.com> on 2013/10/31 02:13:32 UTC
Re: [DISCUSS] Code and design guidelines for OpenMeetings
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, seba.wagner@gmail.com
<se...@gmail.com> 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
> seba.wagner@gmail.com
Re: [DISCUSS] Code and design guidelines for OpenMeetings
Posted by Maxim Solodovnik <so...@gmail.com>.
To unify code style we can export Eclipse settings for OM and put it into
SVN.
I can put mine.
According to the design: I believe there will be more disscussion after
moving to Maven :)
On Thu, Oct 31, 2013 at 8:13 AM, Alexei Fedotov <al...@gmail.com>wrote:
> 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, seba.wagner@gmail.com
> <se...@gmail.com> 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
> > seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: [DISCUSS] Code and design guidelines for OpenMeetings
Posted by Artyom Horuzhenko <ak...@gmail.com>.
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 <al...@gmail.com>
> 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, seba.wagner@gmail.com
> <se...@gmail.com> 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
> > seba.wagner@gmail.com
>