Hello Sebastian, I believe user list should work better after my today's commits Could you please check?
On Wed, Aug 24, 2016 at 10:35 AM, Maxim Solodovnik <[email protected]> wrote: > BTW Sebastien has modified jquery-ui dialog buttons, so now each has a > name, you might wand to try to write some UI tests (using wicket tester or > selenium :)) ) > > On Wed, Aug 24, 2016 at 10:22 AM, Maxim Solodovnik <[email protected]> > wrote: > >> Some actions can be done on the client only (without roundtrips to the >> server :) not much of them, but it can easily be done :)) >> >> On Sun, Aug 21, 2016 at 2:14 PM, [email protected] < >> [email protected]> wrote: >> >>> Yeah same here. Even more confusing when I look at it and kind of >>> remember how it is basically mirroring some of the code and structure that >>> initially was in the OpenLaszlo client :D >>> >>> But overall I think it's pretty cool how less code you can write the UI >>> with. My only concern with Wicket is that you constantly hold the entire UI >>> model also on the Server. Which means UI interactions actually create also >>> load on the server. I think this is a manageable risk. But will be >>> something we need to be careful with when thinking about scaling this to >>> large scenarios. >>> >>> Another potential modularisation for the future would be to separated >>> the conference room UI from the admin/profile/settings UI panels. This >>> would make it easier in the future to plug another conference room UI into >>> it. And the admin panel does not change that often. While the conference >>> room, with all the speed at which the UI frameworks change could mean we >>> got to replace it in a few years again as we might want to use some >>> specific UI framework that has better support for real-time communication. >>> >>> Thanks, >>> Seb >>> >>> >>> >>> >>> >>> 2016-08-21 14:27 GMT+10:00 Maxim Solodovnik <[email protected]>: >>> >>>> by design client is being created in websocket.onConnect method and >>>> being destroyed in websocket.onDisconnect (something like this) >>>> I'll try to double check all this on all steps >>>> Then can fix, and/or describe :) >>>> I wrote this loooong time ago, need to refresh my memories :) >>>> >>>> On Sun, Aug 21, 2016 at 11:24 AM, [email protected] < >>>> [email protected]> wrote: >>>> >>>>> Hi Maxim, >>>>> >>>>> yeah I understand, I think those steps: >>>>> >>>>> 1) change right for the particular user >>>>> 2) send rightUpdated event >>>>> 3) each user will update their list with the data from server Hashmap >>>>> >>>>> When you say (3) "each user will update their list" => You mean the >>>>> visible user list right? Cause that part is done. >>>>> >>>>> => And the rest too. It seems like the issue with (1) is that it does >>>>> not change the right in the RoomPanel.getClient() [which links through to >>>>> the MainPage.client]. >>>>> It seems a bit strange as you request the entire list from >>>>> getRoomClients and the flag seems to be correctly there. >>>>> >>>>> I think this is also the issue when you leave the room and re-enter. >>>>> It kind of assumes you still have all the rights from the previous session >>>>> as the MainPage.client was not reset when you leave and enter to the >>>>> defaults. >>>>> >>>>> Thanks, >>>>> Seb >>>>> >>>>> >>>>> 2016-08-21 14:05 GMT+10:00 Maxim Solodovnik <[email protected]>: >>>>> >>>>>> All clients are being stored in huge hashMap on the server >>>>>> the idea was >>>>>> 1) change right for the particular user >>>>>> 2) send rightUpdated event >>>>>> 3) each user will update their list with the data from server Hashmap >>>>>> I'll double check this next week >>>>>> >>>>>> On Sun, Aug 21, 2016 at 10:57 AM, [email protected] < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I understand that you want to get a stable version out. So >>>>>>> performance is second priority. But you agree to the maths? It's quite >>>>>>> obvious to me that you will run into issues with large number of users >>>>>>> with >>>>>>> that approach. Especially since the re-rendering of the user list >>>>>>> happens >>>>>>> on every right change too. It will re-render the list on every >>>>>>> participant >>>>>>> change. Not just when a new user arrives in the room. >>>>>>> >>>>>>> Btw the issue in the user list when the "actions" panel doesn't >>>>>>> become visible: My use case is: Moderator clicks on the "Grant >>>>>>> moderation >>>>>>> to client xyz" button in the user list. Then on the receiving end, the >>>>>>> status light changes but the actions panel is not there (not on hover, >>>>>>> cause the actions-div is missing) >>>>>>> >>>>>>> And I think the main issue here is that when this event is >>>>>>> propagated to each client, all you send at the moment is >>>>>>> RoomMassage("rightUpdated"). However, this will not update actually the >>>>>>> "Right" on the receiving end. It just re-renders the user list by >>>>>>> calling >>>>>>> "populateItem' but when the populate runs through the list: >>>>>>> >>>>>>> actions.setVisible(room.getClient().hasRight(Right.moderator)); >>>>>>> >>>>>>> room.getClient().hasRight(Right.moderator)=> is still false >>>>>>> >>>>>>> cause it has actually never been updated on each participant. >>>>>>> >>>>>>> The status light changes from green to red. But that is because this >>>>>>> compares the right to the ListItem<Client> item, not the "current" >>>>>>> RoomPanel::getClient() >>>>>>> >>>>>>> If you look at the Flash/ScopeApplicationAdapter version, it >>>>>>> actually always sends around the entire "client" object. The reason for >>>>>>> that was that it is really complicated to figure out which attribute has >>>>>>> changed and then write a custom code for each attribute change. >>>>>>> >>>>>>> I think that part is missing yet for the Wicket/HTML version. >>>>>>> >>>>>>> It seems to me we would need to add either the Client or the >>>>>>> Set<Right)> to the RoomMessage and pass that around + update on the >>>>>>> receiving end. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Thanks, >>>>>>> Sebastian >>>>>>> >>>>>>> >>>>>>> 2016-08-21 13:18 GMT+10:00 Maxim Solodovnik <[email protected]>: >>>>>>> >>>>>>>> Thanks for the pointer, >>>>>>>> but so fat I see no performance degradation >>>>>>>> I'll optimize things as soon as any issues will arise >>>>>>>> >>>>>>>> currently flash room is unable to hold more than 10 people >>>>>>>> (according to one of the user report) >>>>>>>> >>>>>>>> On Sun, Aug 21, 2016 at 8:35 AM, [email protected] < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Maxim, >>>>>>>>> >>>>>>>>> I have seen an example where we store the firstname/lastname in >>>>>>>>> the database instead of the session of the "Client". >>>>>>>>> >>>>>>>>> RoomClientPanel.java::43 >>>>>>>>> >>>>>>>>> User u = getBean(UserDao.class).get(c.getUserId()); >>>>>>>>> >>>>>>>>> Just please keep in mind that access the database is always >>>>>>>>> expensive. It's not really suited for our real-time communication >>>>>>>>> conference room. For instance if there are 500 users in a room you >>>>>>>>> have 500 >>>>>>>>> times a select user.* from users where id = xyz. And that is for >>>>>>>>> every user >>>>>>>>> that enters the room. >>>>>>>>> >>>>>>>>> So 5 users entering with 500 users in the room = 5x500 = 2500 >>>>>>>>> select queries. >>>>>>>>> >>>>>>>>> 100 users entering with 200 users in the room = 100 x 200 = 20000 >>>>>>>>> selection queries. >>>>>>>>> >>>>>>>>> Just for entering the room. >>>>>>>>> >>>>>>>>> It's just like one of those lessons learnt from past OpenMeetings >>>>>>>>> implementations: >>>>>>>>> Do not access the database during the real-time communication part >>>>>>>>> of a conference room. It just doesn't scale. >>>>>>>>> Session vars should be really in the session, not in the database. >>>>>>>>> >>>>>>>>> But it's really more generic: The real-time communication tasks >>>>>>>>> like: userlist, activities, whiteboard events => There should be >>>>>>>>> really no >>>>>>>>> link from those components into the Database. And if so you have to be >>>>>>>>> really careful to make it not interrupting, async and the impact of >>>>>>>>> scaling >>>>>>>>> with 500++ users in a conference room. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sebastian Wagner >>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> WBR >>>>>>>> Maxim aka solomax >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sebastian Wagner >>>>>>> https://twitter.com/#!/dead_lock >>>>>>> [email protected] >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> WBR >>>>>> Maxim aka solomax >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> WBR >>>> Maxim aka solomax >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax > -- WBR Maxim aka solomax
