<div>My 2c (as of talking to myself trying to figure out how to do a prototype of this)...</div><div><br></div>I'm not sure where such service would belong, but it would suffer the same problem that early VoIP systems suffered behind a firewall... While one would be able to open a socket and serve data, there would have to be some kind of uPnP or NAT integration to make it visible to the web (or a tunneling solution as those old http-tunnel stuff).<div>
<br></div><div>Apart from that, I think it would be something like embedding a webserver (or better yet embedding node.js [<a href="http://nodejs.org/">http://nodejs.org/</a>]) in the same level as the javascript API is implemented and allow pure or pre-arranged sockets to be open.</div>
<div><br></div><div>AFAIK, using websockets, the browser initiates a connection with the server, which will proceed upgrading the connection type and opening a two way communication with the server and from now on the application defines the line protocol. At least is what I gathered when doing this: <a href="http://github.com/gleicon/txwebsockets">http://github.com/gleicon/txwebsockets</a></div>
<div><br></div><div>That way, apart from the browser doing this 2-way connection, it could open a standard tcp socket, or better, a kind of special server and register itself on a DHT or tracker (that I think would need to be an obligatory step).</div>
<div><br></div><div>The p2p like mesh network is a great idea, but I think it would take some security heads thinking around on what socket/server models it would be safe to let a browser start, a framework for the tracker registering and a sandbox akin to crossdomain.xml to protect it from turning to a giant botnet.</div>
<div><br></div><div>I think this kind of thinking would be great with w3c behind it (and a wide open discussion on security issues), as I think the node.js approach could be "quicker" to implement browser-wise...</div>
<div><br></div><div>gm</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Fri, Jan 22, 2010 at 6:58 AM, Ivan Žužak <span dir="ltr"><<a href="mailto:izuzak@gmail.com">izuzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">On Fri, Jan 22, 2010 at 03:03, Andrew de Andrade<br>
<div class="im"><<a href="mailto:andrew@deandrade.com.br">andrew@deandrade.com.br</a>> wrote:<br>
</div><div class="im">> comments inline<br>
><br>
> On Thu, Jan 21, 2010 at 5:44 PM, Ivan Žužak <<a href="mailto:izuzak@gmail.com">izuzak@gmail.com</a>> wrote:<br>
</div><div class="im">>> As your Google friend noted, I'm wondering why you'd want to implement<br>
>> this on the HTML5 level, not on the browser (C++) level. Implementing<br>
>> such a protocol within the browser would probably be faster, more<br>
>> secure and a better design choice since the functionality is basically<br>
>> the same for every web application. I'm guessing the reason is that<br>
>> you do not want to achieve this by changing/extending the browser but<br>
>> rather by using new HTML5 technologies instead. Am I right?<br>
><br>
> While I realize that this is best implemented at the browser level, my<br>
> concern is if it will be an idea that would be broadly adopted by all<br>
> browser vendors if it is implemented at that level. It's an idea that<br>
> really has value once you've reached critical mass. For example, this<br>
> would be an extremely potent idea if the two most popular browsers<br>
> have implemented this by 2014 to 2015 or so. HTML5 is a web technology<br>
> spec. I imagine that putting it in the spec would greatly increase the<br>
> chances of browsers supporting this functionality.<br>
><br>
> However, I am not familiar with the politics that govern whether or<br>
> not browser product managers implement these features at the browser<br>
> level?<br>
><br>
> Being pragmatic, do you think it's possible to get widespread adoption<br>
> quickly for a feature like this as the browser level or do you agree<br>
> that this would be more likely to be adopted quickly if it was part of<br>
> a W3C spec?<br>
<br>
</div>I think there are two separate issues here. First, if this idea is to<br>
be widely adopted and implemented - I believe there must be an open<br>
specification of it. And there are basically two ways of doing this -<br>
by having it proposed by a specific browser vendor or by having it<br>
proposed by a standardization organisation like the W3C or IETF. And<br>
yes, you're right - having something proposed by W3C versus a specific<br>
browser vendor - I'd say it's more likely to catch on if the W3C puts<br>
it foot behind it.<br>
<br>
Second, there is a difference between a) implementing the idea in the<br>
browser engine versus b) implementing it as a part of the application<br>
executing on the browser engine. The same functionality can be<br>
achieved by defining a protocol which browsers would implement as a<br>
part their engine (e.g. using some other available protocol instead of<br>
WebSockets (e.g. plan old HTTP or SPDY) and threads instead of<br>
WebWorkers) or by creating web applications where each application<br>
would implement this protocol itself using application level<br>
technologies (i.e. the proposed WebSockets and WebWorkers tech). In<br>
essence, it doesn't matter which technology you use to implement it as<br>
long as it implements the protocol you define. So, since technologies<br>
used for implementation are open and available, why would the W3C<br>
wan't this implemented at the application level versus the browser<br>
level? Both scenarios require changes to both the server of an<br>
application and the browser.<br>
<div class="im"><br>
>> If so, then a major problem is that the browser is not a network<br>
>> server, rather only a client. In order for a browser A to connect<br>
>> using WebSockets to a browser B which executes some process, browser B<br>
>> must expose a network accessible end-point to which that process is<br>
>> tied i.e. the browser must expose TCP/IP end-point. I guess that the<br>
>> NAT traversal problem Melvin mentioned basically covers this.<br>
>><br>
><br>
> Assuming that this idea really only sees adoption within a few years,<br>
> won't IPv6 resolve the issue of NAT traversal?<br>
<br>
</div>I'm not familiar with NAT traversal or what other novelties IPv6<br>
introduces other than a broader address space, so I may be wrong when<br>
saying this but - only by switching from IPv4 to IPv6 will not solve<br>
this problem. The browser would still be a client initiating<br>
connections to other network entities, not a server accepting<br>
connections from those clients. Or as Mike put it: "WebSockets doesn't<br>
let you open arbitrary ports and listen on them". I'm not getting into<br>
how hard this is to do, I'm just saying that it's something which is<br>
necessary.<br>
<div class="im"><br>
>> In a broader context of connecting both servers and client devices<br>
>> into a large network for scalable execution of applications, your idea<br>
>> reminds me of a recent blog article I read:<br>
>> <a href="http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html" target="_blank">http://highscalability.com/blog/2009/12/16/building-super-scalable-systems-blade-runner-meets-autonomic.html</a>.<br>

>> Definitely have a look at it - it's a bit on the visionary side and<br>
>> longish, but worth it. I believe a planet-wide execution platform<br>
>> consisting of every network device will eventually happen and that's<br>
>> why I think we should all be contributing in that direction, which<br>
>> your idea definitely is.<br>
><br>
> I took a brief look. This article looks very interesting. I'm going to<br>
> have a gander at it tomorrow. Maybe I'll shoot the HighScalability<br>
> people an email and see if they want to comment on this idea on their<br>
> blog.<br>
<br>
</div>I believe Todd from HighScalability will like the idea. It's a<br>
direction in which lots of people see the Internet/WWW going. I hope<br>
you didn't get me wrong with my comments - I like your idea of<br>
distributing the load towards clients.<br>
<br>
Cheers,<br>
<font color="#888888">Ivan<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>More cowbell, please !<br>
</div>