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
