Re: client/admin modularity rambling
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.wag...@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 > >> 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 >> 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.fedo...@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 > > >> >> 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.fedo...@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 < >> solomax...@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 agr
Re: client/admin modularity rambling
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 > 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 > 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.fedo...@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 > > >> 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.fedo...@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 < > solomax...@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.fedo...@gmail.com>wrote: > >> >> > > >> >> >> Hello folks, > >> >> >> > >> >> >> I have recently participated in discussions on openmeetings > >> management > >> >> >> interface. Open of possible options we have discussed w
Re: client/admin modularity rambling
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 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 > 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 >> 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.fedo...@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 > > >> >> 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.fedo...@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
Re: client/admin modularity rambling
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 > 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 >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 > > 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.fedo...@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 < > solomax...@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 us
Re: client/admin modularity rambling
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 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 > 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.fedo...@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 > > >> 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.fedo...@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 whiteb
Re: client/admin modularity rambling
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 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 > 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 >> 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.fedo...@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
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 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 > 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 >> 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.fedo...@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
*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 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 > 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.fedo...@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
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 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 > 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
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 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