- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 17 Dec 2009 21:46:23 +0000 (UTC)
- To: Nick Lothian <nlothian@educationau.edu.au>
- Cc: Andrei Popescu <andreip@google.com>, Anne van Kesteren <annevk@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Ben Murdoch <benm@google.com>
On Fri, 18 Dec 2009, Nick Lothian wrote: > > > > > > > > However, in this case we need to even more, because otherwise > > > > there's no guarantee that a user with one browser could chat to a > > > > user with another browser, which makes the whole exercise > > > > pointless. > > > > > > Won't that go via a server, which could potentially transcode? > > > > When we do go through a server, it would certainly be better if the > > server didn't have to transcode every frame. That's a lot of load on > > the server. But I think ideally we'd eventually come up with a > > client-to-client protocol, and so the server couldn't transcode even > > if it wanted to. > > Do you consider the client-to-client protocol to be in scope at the > moment, or is that far-future work? I don't know. If we do introduce a client-to-client protocol, I'd imagine we'd want to reuse an existing one, so that we don't have to resolve all the NAT traversal issues. (Simplicity wouldn't be as high a priority in this case as in the client-server case, since we'd expect far fewer independent implementations, so there'd be less to gain by developing a whole new protocol than there was with, e.g., Web Sockets.) I'm not familiar with existing protocols for this, though. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 17 December 2009 21:46:52 UTC