Will do. I should be able to come back to you in 1-2 days. Thanks Seb
Sent from my iPhone > On 1/09/2016, at 8:18 PM, Maxim Solodovnik <[email protected]> wrote: > > 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
