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/04/22 09:43:03 UTC
client/admin modularity rambling
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
Re: client/admin modularity rambling
Posted by Alexei Fedotov <al...@gmail.com>.
I fully support going step by step. Users won't accept too many
changes at once, and we will have time to fix bugs.
--
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 Sat, Jun 22, 2013 at 3:54 AM, seba.wagner@gmail.com
<se...@gmail.com> wrote:
> Hi Alexei,
>
> I understand your concerns however, as a complete HTML5 migration is
> technically not possible yet the idea was to migrate those parts where we
> have a clear technical vision on how it can work.
>
> So actually the plan for OpenMeetings 3.0 is: OpenMeetings 3.0 will deliver
> everything in HTML5 except the conference room.
>
> The only HTML5 real-time component would be the chat in the dashboard.
>
> Sebastian
>
>
>
>
> 2013/6/17 Alexei Fedotov <al...@gmail.com>
>
>> My intention was to ship OM 3.0 quicker, by means of keeping anything
>> except admin in OpenLaszlo. This would help users to adopt the new
>> thing. Anyway, I see you are far ahead the admin.
>>
>> --
>> With best regards / с наилучшими пожеланиями,
>> Alexei Fedotov / Алексей Федотов,
>> http://dataved.ru/
>> +7 916 562 8095
>>
>>
>> On Thu, Apr 25, 2013 at 12:25 PM, Maxim Solodovnik <so...@gmail.com>
>> wrote:
>> > 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
Re: client/admin modularity rambling
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Alexei,
I understand your concerns however, as a complete HTML5 migration is
technically not possible yet the idea was to migrate those parts where we
have a clear technical vision on how it can work.
So actually the plan for OpenMeetings 3.0 is: OpenMeetings 3.0 will deliver
everything in HTML5 except the conference room.
The only HTML5 real-time component would be the chat in the dashboard.
Sebastian
2013/6/17 Alexei Fedotov <al...@gmail.com>
> My intention was to ship OM 3.0 quicker, by means of keeping anything
> except admin in OpenLaszlo. This would help users to adopt the new
> thing. Anyway, I see you are far ahead the admin.
>
> --
> With best regards / с наилучшими пожеланиями,
> Alexei Fedotov / Алексей Федотов,
> http://dataved.ru/
> +7 916 562 8095
>
>
> On Thu, Apr 25, 2013 at 12:25 PM, Maxim Solodovnik <so...@gmail.com>
> wrote:
> > 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
Re: client/admin modularity rambling
Posted by Alexei Fedotov <al...@gmail.com>.
My intention was to ship OM 3.0 quicker, by means of keeping anything
except admin in OpenLaszlo. This would help users to adopt the new
thing. Anyway, I see you are far ahead the admin.
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Thu, Apr 25, 2013 at 12:25 PM, Maxim Solodovnik <so...@gmail.com> wrote:
> 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 <al...@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 <so...@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
Re: client/admin modularity rambling
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@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 <so...@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
Re: client/admin modularity rambling
Posted by Maxim Solodovnik <so...@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 <al...@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 <so...@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
Re: client/admin modularity rambling
Posted by Alexei Fedotov <al...@gmail.com>.
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 <so...@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 <al...@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 <so...@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
Re: client/admin modularity rambling
Posted by Maxim Solodovnik <so...@gmail.com>.
The only advantage I can see in separating Admin is: we can "force" users
to use HTML5 version.
I hope in upcoming 3.0.0 we can do this without separation, since only few
areas are currently left unimplemented
On Mon, Apr 22, 2013 at 9:05 PM, Maxim Solodovnik <so...@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 <al...@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 <so...@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
Re: client/admin modularity rambling
Posted by Maxim Solodovnik <so...@gmail.com>.
*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 <al...@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 <so...@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
Re: client/admin modularity rambling
Posted by Alexei Fedotov <al...@gmail.com>.
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 <so...@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 <al...@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
Re: client/admin modularity rambling
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <al...@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