- room enter: Most probably you are right :( I'm not really good in all those "room enter" methods so I have added additional method I would really appreciate the help in this. What I need is: room enter by given SID and room id with exit button visible :) (so the user entered is treated as "normal" OM user, not external)
- room close: I have added JS call handling removing of room from the DOM or just replacing the DOM "the room" element with room list element. On Mon, Jun 10, 2013 at 12:37 PM, [email protected] < [email protected]> wrote: > Quote: > *Additionally things are simplier in 3.0: > - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1)* > > => This is not true. There is such a mechanism, however currently 3.0 does > not use it. So it will first connect to the scope "hibernate" and then to > the scope "$roomId". > However it could be reworked to work like you describe. There is a param > "scopeRoomId", if that is specified it will directly connect to the scope > of the room instead of going to hibernate. However there is end the end > always a check: > It will request the conference session object from the user and compare > the roomId with the scopeRoomId, if that test is OK it will directly > connect to the $roomId, if that test fails, it will connect to the scope > hibernate and use the "normal" mechanism to get the $roomId and build an > URL with it. This check is mainly for security reasons, so that by just > manipulating the URL, the user can gain access to random rooms. > > *- Room leave just removes div with embedded flash from the DOM and > displays > main interface (use case 2)* > => Again, it could be done like that but I am not sure if it currenlty > really does. > > Sebastian > > > > > > 2013/6/10 Maxim Solodovnik <[email protected]> > >> +1 for displaying "Connection has been lost" >> >> Additionally things are simplier in 3.0: >> - Room enter connects to rtmp://xyz/openmeetings/$roomId (use case 1) >> - Room leave just removes div with embedded flash from the DOM and >> displays >> main interface (use case 2) >> >> >> On Mon, Jun 10, 2013 at 6:55 AM, [email protected] < >> [email protected]> wrote: >> >> > Hi Artyom, >> > >> > Quote: *When a user looses his connection he >> > get 3 attempts to reconnect. * >> > => Which is a funny co-incident. It should not do that, the 3 times try >> are >> > only for when you do your initial set up. It does try 3 times rtmp and >> then >> > switches to rtmpt. >> > >> > *If we don't, I offer to show user an error message without reconnection >> > attempts because unexpected leaving the room looks as a bug.* >> > =>I agree. It should not even try a single time. There should be just an >> > error message "Your lost the connection, please reload the application". >> > That would be the correct behaviour. Everything else is just confusing, >> > cause at the moment it looks like it does some "auto-reconnect". But >> there >> > is no such feature. >> > The only thing to make sure is that room-leave and room(-re)-entering >> still >> > works correctly: >> > - Room enter disconnects from rtmp://xyz/openmeetings/hibernate to >> > rtmp://xyz/openmeetings/$roomId (use case 1) >> > - Room leave disconnects from rtmp://xyz/openmeetings/$roomId to >> > rtmp://xyz/openmeetings/hibernate (use case 2) >> > - If a user has rtmpt (you can test that by chaning the rtmp port to >> some >> > rubbish in the config.xml and clear your cache), then room enter and >> leaver >> > should still work the same _but_ using rtmpt instead of rtmp all the >> time. >> > (use case 3 [rtmpt-enter] and 4 [rtmpt-leave]) >> > >> > You can verify if everything works correctly if you goto Administration >> > >> > Connections. If the re-connect on rooms leave is correct, then exiting >> and >> > re-entering a room with a user in another session will just increment >> the >> > ID of the roomClient by : >> > Exiting the room +1, >> > Renering the room +2 (one time SWF8 rtmp connection +1, one time SWF11 >> > rtmp-connection +1) >> > If you just close your browser it does not increment the id by +1, just >> > closing your browser will just disconnect and send appropriate messages >> to >> > everybody. >> > >> > Administration > Connections is quite handy for development purpsose. On >> > click of an entry you can see every session attribute in the RoomClient. >> > You currently always see 2 entries per user as soon as he is in the >> > conference room. Every user has two separated rtmp connections, one for >> the >> > SWF8 legacy code and one for the "new" SWF11 container. SWF11 does >> handle >> > all the Audio/Video stuff. SWF11 does only connect when you really need >> > Audio/Video. So only in the conference room and maybe in the recording >> > section. >> > >> > Maybe part of this information is redundant for you Artyom, however if >> you >> > have any further questions please let me know. >> > >> > Thanks, >> > Sebastian >> > >> > >> > 2013/6/7 Artyom Horuzhenko <[email protected]> >> > >> > > Sebastian, let me explain our trouble. When a user looses his >> connection >> > he >> > > get 3 attempts to reconnect. If all of the attempts are failed, the >> user >> > > sees an error message, otherwise - the user reconnects to dashboard. >> We >> > are >> > > discussing idea about reconnecting to room again instead of >> dashboard. I >> > > agree with you that whiteboard, userlist etc should be reloaded, but I >> > want >> > > to know if we really need restoring connection. If we don't, I offer >> to >> > > show user an error message without reconnection attempts because >> > unexpected >> > > leaving the room looks as a bug. >> > > 07.06.2013 13:28 пользователь "[email protected]" < >> > > [email protected]> >> > > написал: >> > > > >> > > > Sorry I get lost in that kind of discussion. >> > > > >> > > > Artyom started a vote, quote: >> > > > >> > > > *I think in this case the functionality like this is useless, >> > > > it should be removed at all or improved to allow users reconnect >> > without >> > > > leaving the room. I offer to vote about this thing: >> > > > >> > > > +1 fix leaving rooms >> > > > 0 don't change anything >> > > > -1 remove reconnection functionality at all* >> > > > >> > > > So what does +1 mean *fix leaving the room* ... what has that to do >> > with >> > > > what you say Alexei ?! >> > > > In fact I don't think that there is anything to fix with that >> > reconnect. >> > > > >> > > > And whatever Artyom proposed has nothing todo with fixing an user >> that >> > > lost >> > > > the connection. >> > > > >> > > > About the *reconnect when user lost connection* feature: >> > > > I think in another thread I tried to explain: When the connection is >> > > lost, >> > > > simply reconnecting the rtmp-connection has _no_ meaning, as you >> don't >> > > know >> > > > how long the user was away. You need to re-sync the whiteboard, the >> > > videos >> > > > list, the list of participants and the list of current screensharing >> > > > sessions. So in fact you can simply clean everything and re-login >> the >> > > user. >> > > > The same the other way round, everybody that was in the room, will >> have >> > > to >> > > > re-initialize the user that was lost. Simply connecting the >> > > rtmp-connection >> > > > will just make the situation worse as it may look like *working* >> but in >> > > > fact nothing really *works*. >> > > > >> > > > So I am sorry but from my point of view you mix things together that >> > have >> > > > nothing todo with each other: >> > > > Reconnecting while leaving the room VS connection lost. >> > > > >> > > > Sebastian >> > > > >> > > > >> > > > >> > > > 2013/6/7 Alexei Fedotov <[email protected]> >> > > > >> > > > > I used the following arguments: >> > > > > >> > > > > 1. Skype tries to re-connect when the connection is lost (though >> it >> > > > > works awfully). Why should not we? >> > > > > 2. When one re-connects (doesn't matter how, maybe after the flash >> > > > > crash), she should reappear in the place where she was before the >> > > > > break. This simplifies reestablishing connection. I think this is >> > > > > useful behavior. >> > > > > >> > > > > Combining two of these arguments we get "room reconnect" feature >> > which >> > > > > can potentially improve the user experience. >> > > > > >> > > > > This is close to the second variant, which is called the cluster >> > > > > re-connect. >> > > > > >> > > > > -- >> > > > > With best regards / с наилучшими пожеланиями, >> > > > > Alexei Fedotov / Алексей Федотов, >> > > > > http://dataved.ru/ >> > > > > +7 916 562 8095 >> > > > > >> > > > > >> > > > > On Fri, Jun 7, 2013 at 12:47 PM, [email protected] >> > > > > <[email protected]> wrote: >> > > > > > Hallo Artyom, >> > > > > > >> > > > > > *We know that reconnection works somehow* >> > > > > > >> > > > > > Just to be _very_ clear. There is no such feature! >> > > > > > >> > > > > > There is a co-incident that may _look like_ a reconnect. >> > > > > > >> > > > > > The *feature* is that the flash clients does try to connect 3 >> times >> > > to >> > > > > the >> > > > > > rtmpconnection. >> > > > > > This initial connection try out is _never_ cleared. So if your >> > > > > connections >> > > > > > gets lost (and you did not have initially the bad luck of using >> > your >> > > 3 >> > > > > > tries), the rtmp connection does reconnect. >> > > > > > However this is just a funny co-incident. This was never the >> intend >> > > to >> > > > > > re-connect the rtmp connection when it gets lost while the user >> is >> > > > > already >> > > > > > in the meeting. >> > > > > > >> > > > > > So what other types of *reconnect* are you refering to? >> > > > > > There is one reconnect when the user leaves the room, that is >> when >> > he >> > > > > > switches the rtmp connection URL from: >> > > > > > rtmp://host:port/openmeetings/$roomId >> > > > > > to >> > > > > > rtmp://host:port/openmeetings/hibernate (default channel) >> > > > > > >> > > > > > The same *re-connect* happens when he enters the room. He has to >> > > switch >> > > > > > from the default/global scope to the room scope. >> > > > > > >> > > > > > There is no option to remove this functionality, if the user >> does >> > not >> > > > > > change the rtmp-connection he can never receive any messages and >> > > connect >> > > > > to >> > > > > > the streams of the conference room. >> > > > > > This is the concept of streaming servers: >> > > > > > If you want to connect to a particular room and receive update >> > > > > > notifications of events of that room => Connect/Subscribe to >> that >> > > URL! >> > > > > > Connecting/Subscribing to that URL cannot happen without a >> > reconnect >> > > when >> > > > > > you enter or leave the room. >> > > > > > >> > > > > > Btw: THis functionality is actually the basis for any kind of >> > > clustering >> > > > > as >> > > > > > the point where somebody enters and leaves the room is when it >> gets >> > > > > > re-directed to another server. So without that reconnect, there >> is >> > no >> > > > > > clustering. >> > > > > > >> > > > > > So those are the different version of "reconnect" that currently >> > > exist. >> > > > > > >> > > > > > Can you please clarify what exactly you meant with >> *reconnecting*? >> > > What >> > > > > > kind of reconnecting? >> > > > > > And did you see the impact of your proposal? >> > > > > > >> > > > > > Thanks, >> > > > > > Sebastian >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > 2013/6/7 Artyom Horuzhenko <[email protected]> >> > > > > > >> > > > > >> Hello collegues, >> > > > > >> >> > > > > >> I want to discuss reconnection again and decide what should we >> do >> > > with >> > > > > it. >> > > > > >> We know that reconnection works somehow: users leave the room >> > after >> > > > > >> reconnection. I think in this case the functionality like this >> is >> > > > > useless, >> > > > > >> it should be removed at all or improved to allow users >> reconnect >> > > without >> > > > > >> leaving the room. I offer to vote about this thing: >> > > > > >> >> > > > > >> +1 fix leaving rooms >> > > > > >> 0 don't change anything >> > > > > >> -1 remove reconnection functionality at all >> > > > > >> >> > > > > >> I made some experiments and suppose that reconnection can be >> fixed >> > > > > without >> > > > > >> global changes in code, but requires deep testing. Anyway, my >> vote >> > > is >> > > > > +1. >> > > > > >> >> > > > > > >> > > > > > >> > > > > > >> > > > > > -- >> > > > > > Sebastian Wagner >> > > > > > https://twitter.com/#!/dead_lock >> > > > > > http://www.webbase-design.de >> > > > > > http://www.wagner-sebastian.com >> > > > > > [email protected] >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Sebastian Wagner >> > > > https://twitter.com/#!/dead_lock >> > > > http://www.webbase-design.de >> > > > http://www.wagner-sebastian.com >> > > > [email protected] >> > > >> > >> > >> > >> > -- >> > Sebastian Wagner >> > https://twitter.com/#!/dead_lock >> > http://www.webbase-design.de >> > http://www.wagner-sebastian.com >> > [email protected] >> > >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
