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
