openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: client/admin modularity rambling
Date Thu, 25 Apr 2013 10:45:24 GMT
Having two apps to maintain sounds to me even more work then having one app.
I think we have enough work upfront with the HTML5 interface.

>From my experience you normally try to integrate as much as possible into a
single app, not the other way round.
Compare for example other web-application that have a user administration
like any kind of cms, for example wordpress, joomla, moodle whatever: Do
they provide two separated apps, one for the admin and one for the end user?

I also do not really see this strict separation of admins and normal users.
There are already for example "org-moderators". They are in between of
admins and users. So do they also then get their own app or do they got a
light-weighted version of the admin app or ?

Or course modularity is a good thing, but it can be achieved with different
tools and methods then packaging two apps.

Making our app split up like that will also not help others to re-user our
modules.
The main reason why others can't re-use is our technology stack and design.
For example we could build a plugin loader and make any of our content
sections a real module that communicates with the container over a defined
API. That makes it possible to replace one module with another which would
be helpful.
But just splitting up into two apps is no improvement in terms of
modularity from my point of view.

Sebastian



2013/4/25 Maxim Solodovnik <solomax666@gmail.com>

> 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
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

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