@Daniel thanks for the excellent & extended testing on your host environments. That the screensharing does not close on the clients after the publisher hit the *stop* is definitly a bug that we did already fix in previous versions.
The check to do not start the ScreenSharing Application several time on the same client machine would be also quite usefull thats right. It is however a bit complex as you need either handle on server side a *flag* that marks clients that run the screensharing => that is only possible if the user hits the *start-sharing* or *start-recording* button, otherwise there is no connect from the client to the server. Or you try to implement some hook that checks on startup of the screensharing client if its already running => I am not sure if the Java Web-Start Sandbox allows access to the process/task-manager to check that ... also it would be a bit nasty as you would need to download the hole app first, start it to see that you have it already running :-/. So the only acceptable fix would be to open an additionaly socket from the screensharing client to the server as long as the client is open. That would be sth. for upcoming version, I'll add it to our Issue tracker. Thanks again Sebastian 2011/7/29 Pavel Rebriy <pavel.reb...@gmail.com> > +1 from me too! > > Mikhail Fursov <mike.fursov <at> gmail.com> writes: > > > > > Used OpenMeetings yesterday for our local video web conference with 3 > > sites online . It worked flawlessly. > > > > +1 from me! > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.wagner-sebastian.com seba.wag...@gmail.com
