- From: <piranna@gmail.com>
- Date: Mon, 22 Jul 2013 10:36:40 +0200
- To: Iñaki Baz Castillo <ibc@aliax.net>
- Cc: Roman Shpount <roman@telurix.com>, cowwoc <cowwoc@bbs.darktech.org>, tim panton <thp@westhawk.co.uk>, "public-webrtc@w3.org" <public-webrtc@w3.org>
>> I agree, but we should start a discussion on another thread about how >> to develop a pure, server-less browser-to-browser signaling without >> parasiting other protocols since it's not really professional. > > Please piranna, let's focus on the thread subject. WebRTC is not about > converting a browser in a no-browser. The browser needs to access some > website (so HTTP protocol takes place), load the WebRTC JS app and > then use RTC. This is not about connecting with other browsers using > p2p protocols without navigating a web. > I admit I'm too much focused on my personal use case, but I'm not the only one that thinks web it's too much server-centric. WebRTC allow a posibility to fix this, and I don't find it bad, so why we should still keep attached to some server-oriented issues? I find this a point of failure regarding censorship and anonimity between others, and also having so present this server-centric architecture there are having issues with some functionality otherway acceptable. For example, why is a security issue read files selected by the user with an input tag using FileReader with a page loaded from file://, but if the page is loaded from http://localhost is valid? It doesn't make sense to me... Regarding to WebRTC, it's true it doesn't have this restrictions, but I think decissions should also have in mind this full server-less use case... -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
Received on Monday, 22 July 2013 08:37:27 UTC