[RTW] My biggest concern

[Robin Raymond]

I've been quiet on the list and perhaps this has already been discussed.

My primary concern has to do with the way users interact with their browsers
and tying the lifetime of the streaming sessions to the javascript on a
webpage. Given the proposals, javascript will likely be used to setup
streaming sessions and thus there will need to be automatic clean-up of
these sessions when the related javascript objects are closed when a website
page is "closed". This in my opinion can cause major issues with users.

In my own situation, I have a list of common viewed websites at the top of
my browser and a simple accidental click will go to those new pages. I
frequently click on those pages accidentally. If I'm simply viewing email,
no big deal, I hit the back and while I'm annoyed I can easily recover. With
a call in progress this will no longer be the case. The entire session state
will be destroyed, the calls will tear down immediately as a result of the
lifetime of streams being tied to the lifetime of the javascript objects on
the page.

I think practically speaking this will happen often. Users will be in a call
with each other and say "have you seen that new cool video", and most non
tech savvy users will simply type the search into their browser window and
their search bar and the browser javascript will be torn down and bring down
all the RTP streams thus ending any active communication as a result. How
annoying it would be to have established calls torn up/down based on typical
browser usage by a user! Expecting users not to navigate while calling is
impractical and expecting users will open new browser tabs will be
unworkable, especially to anyone like me has had to support family members
confusion over browser tabs and accidentally closing what they are working
on...

I think the depth of this issue is unique to RTC-WEB proposal. Of course,
I've seen this issue with videos and other places - where you are in the
middle of watching a video, click to a new page and then come back to have
the video start over and if it doesn't index itself properly will have to
download and play from the beginning. Youtube has done a lot to solve those
usability issues by doing many intelligent work arounds and keeping
currently locations pretty accurate when going "back". But I fear no such
work arounds will be easy or possible with RTC-WEB and solutions could open
up new cans of security worms. For example, reopening a closed page with the
"back button" could cause re-open a previously accidentally closed media
sessions but could also open an intentionally closed sessions. Re-opening
the connection automatically based on going "back" to a previous page could
be embarrassing if you did actually intend to end the call and then the
microphone was re-opened automatically broadcasting to the previous person
you were connected.

To keep media sessions alive even as users click around implies the lifetime
of the call exists outside the active browser page. But this opens up other
issues. For example, when does the call get automatically torn down if they
leave the site? Or where are the controls for the call going to exist
outside the site if the page with the controls is closed? (and the browser
would have no understanding of what controls should be presented when
navigating off the page since every website will have their own call control
definitions).

So maybe I'm missing something important like other browser future
technologies introduced in conjunction with RTC-WEB (e.g. application based
web sites) but I don't understand how RTC-WEB is going to get around these
javascript-tied-to-a-webpage lifetime issues...

Regards,
Robin Raymond
hookflash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110328/dbaeb8d8/attachment.html>