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 <solomax...@gmail.com>
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 <solomax...@gmail.com>
> 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, seba.wag...@gmail.com <
>> seba.wag...@gmail.com> 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 <solomax...@gmail.com>:
>>>
>>>> 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, seba.wag...@gmail.com <
>>>> seba.wag...@gmail.com> 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 <solomax...@gmail.com>:
>>>>>
>>>>>> 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, seba.wag...@gmail.com <
>>>>>> seba.wag...@gmail.com> 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 <solomax...@gmail.com>:
>>>>>>>
>>>>>>>> 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, seba.wag...@gmail.com <
>>>>>>>> seba.wag...@gmail.com> 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
>>>>>>>>> seba.wag...@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> WBR
>>>>>>>> Maxim aka solomax
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> seba.wag...@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> seba.wag...@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> seba.wag...@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
