openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <solomax...@gmail.com>
Subject Re: client/admin modularity rambling
Date Thu, 25 Apr 2013 08:25:41 GMT
Hello Alexei,

First of all it is unclear to me WHY should we separate admin.
It will be impossible to have open websocket if user will close/open pages
this is why we agreed to use "single page ajax interface"
After switching to 2 applications mode the things will getting even worst.


On Thu, Apr 25, 2013 at 3:14 PM, Alexei Fedotov <alexei.fedotov@gmail.com>wrote:

> Hello Maxim,
> too quickly going are we.
>
> So what is the problem with chat when talking about admin modularity?
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Mon, Apr 22, 2013 at 6:05 PM, Maxim Solodovnik <solomax666@gmail.com>
> wrote:
> > *1)* >> we should embed a small jabber server into openmeetings
> > This is currently sounds like "unrealistic" "too far in the future" plan
> :)
> > Additionally it is introduces more "hard to implement" tasks:
> > 1) we need global chat (current functionality) not sure how this can be
> > implemented.
> > 2) we need per room chat (current functionality) additional code will
> need
> > to be written to implement that
> > 3) we need chat history for all types of chats (current functionality)
> >
> > Additionally I know no "small jabber servers" written in java and can be
> > used as a integratable module. As per your own requirement OM is
> currently
> > requires too many 3rd party SW need to be configured, currently you
> > proposing to add additional 3rd party program.
> >
> > *2)* >> There is no chat inside admin app
> > In current HTML5 implementation chat is global function (like in FB or
> > Gmail), so chat there is chat inside admin app actually
> >
> > *3)* >>I also think that we have "no wicket" app for admin. ... All admin
> > UI can be re-used from standard http console
> > It is unclear what does it mean could you please provide some use cases?
> >
> >
> >
> > On Mon, Apr 22, 2013 at 8:46 PM, Alexei Fedotov <
> alexei.fedotov@gmail.com>wrote:
> >
> >> Good. I don't see any disadvantages of separating admin. Let's start
> >> with listing these disadvantages.
> >>
> >> > After separation of Admin it will be harder to sync chat messages for
> >> example.
> >> Why? Well, strategically we should embed a small jabber server into
> >> openmeetings. As a separate module. Chat messages should be
> >> synchronized via standard jabber protocol. There is no chat inside
> >> admin app. I also believe that admin app can be opened at the next tab
> >> to openmeetings.
> >>
> >> I also think that we have "no wicket" app for admin. All admin UI can
> >> be re-used from standard http console. Still, that's another part of
> >> discussion.
> >>
> >> --
> >> With best regards / с наилучшими пожеланиями,
> >> Alexei Fedotov / Алексей Федотов,
> >> http://dataved.ru/
> >> +7 916 562 8095
> >>
> >>
> >> On Mon, Apr 22, 2013 at 5:39 PM, Maxim Solodovnik <solomax666@gmail.com
> >
> >> wrote:
> >> > Hello Alexei,
> >> >
> >> > It is possible to create different wicket app for admin, but I see no
> >> > reasons for it.
> >> > In my opinion there will be less advantages than disadvantages after
> such
> >> > separation.
> >> >
> >> > While discussing HTML5 OM design Sebastian and I were agreed to have
> >> > "single page" architecture this will allow to have single websocket
> per
> >> > user opened allowing as to push any system messages to the user no
> matter
> >> > what OM area he/she is currently using.
> >> > After separation of Admin it will be harder to sync chat messages for
> >> > example.
> >> >
> >> >
> >> > On Mon, Apr 22, 2013 at 2:43 PM, Alexei Fedotov <
> >> alexei.fedotov@gmail.com>wrote:
> >> >
> >> >> Hello folks,
> >> >>
> >> >> I have recently participated in discussions on openmeetings
> management
> >> >> interface. Open of possible options we have discussed was having
> admin
> >> >> module separated from the code base. Modularity helps debugging
> things
> >> >> and shipping releases. Also being modular helps others to re-use our
> >> >> code, and re-usability if one of our competitive advantages. BTW,
> >> >> that's why I support our client code to be in a separate module -
> >> >> people want having their client UIs customized.
> >> >>
> >> >> Java has a special API for managing applications [1]. It basically
> >> >> provides the ability of changing internal state of the application
> >> >> (flags, parameters, etc) with minimal UI beautification. While there
> >> >> is no requirement to use this interface, at least it worth taking a
> >> >> look. This allows using standard jconsole or other HTTP-based
> consoles
> >> >> to manage an applications.
> >> >>
> >> >> Which questions help understanding if some functionality worth a
> >> >> separate module?
> >> >> * Does this module have a different customer base? (May be true for
> >> >> whiteboard, and the server code with client code excluded.)
> >> >> * Is the module big enough? (True for both client and server
> modules.)
> >> >> * Are changes to this module independent from openmeetings changes?
> >> >> (True for whiteboard, webstart client, admin console UI.)
> >> >>
> >> >> I wonder if it is possible to build independent modules in wicket.
> >> >>
> >> >> [1] http://en.wikipedia.org/wiki/Java_Management_Extensions
> >> >>
> >> >> --
> >> >> With best regards / с наилучшими пожеланиями,
> >> >> Alexei Fedotov / Алексей Федотов,
> >> >> http://dataved.ru/
> >> >> +7 916 562 8095
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > WBR
> >> > Maxim aka solomax
> >>
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>



-- 
WBR
Maxim aka solomax

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message