Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

Iñaki Baz Castillo <ibc@aliax.net> Mon, 03 October 2011 12:21 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72221F84A2 for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 05:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.637
X-Spam-Level:
X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv+TaEA2dUuy for <rtcweb@ietfa.amsl.com>; Mon, 3 Oct 2011 05:21:49 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D85D421F84B5 for <rtcweb@ietf.org>; Mon, 3 Oct 2011 05:21:48 -0700 (PDT)
Received: by vws5 with SMTP id 5so4233580vws.31 for <rtcweb@ietf.org>; Mon, 03 Oct 2011 05:24:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.89.177 with SMTP id bp17mr13877631vdb.447.1317644690820; Mon, 03 Oct 2011 05:24:50 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 3 Oct 2011 05:24:50 -0700 (PDT)
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com>
Date: Mon, 3 Oct 2011 14:24:50 +0200
Message-ID: <CALiegf=PU3ec6dSh-9NBLrTz7Q8HJb74WitqfmV+2sHqucDyMA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Markus.Isomaki@nokia.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2011 12:21:49 -0000

2011/10/3  <Markus.Isomaki@nokia.com>om>:
> - The first-order requirement is that the browser and/or the JS app, whoever needs to act, has to be able to get events of interface switching in the same way as native apps can. If it were only the browser who was required to get them, we could set standards aside, and declare that the browser does this as any other app. But if it is the JS app that needs to do something, then we may need something new as a JS API. I have no clue at the moment if the JS apps can learn about this kind of events. And this is clearly not a RTC-Web specific requirement, but a generic one. I do know that browsers or HTTP libraries can re-send requests etc. based on IP address change, but I don't know what a JS Websocket client can do, if anything.

In WebSocket a disconnect() event will be called by JS API if the
connection is terminated (this can occur when the server explicity
terminates the connection or when the WebSocket client tries to send a
message over the WebSocket connection and gets an error because the
connection "does not work anymore"). For the last case, a pinging
mechanism from the client is a good choice.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>