[whatwg] Web-sockets + Web-workers to produce a P2P website or application

On Fri, Jan 22, 2010 at 6:58 AM, Ivan ?u?ak <izuzak at gmail.com> wrote:

> I think there are two separate issues here. First, if this idea is to
> be widely adopted and implemented - I believe there must be an open
> specification of it. And there are basically two ways of doing this -
> by having it proposed by a specific browser vendor or by having it
> proposed by a standardization organisation like the W3C or IETF. And
> yes, you're right - having something proposed by W3C versus a specific
> browser vendor - I'd say it's more likely to catch on if the W3C puts
> it foot behind it.
>


I'm wondering if anyone from either webkit, mozilla, opera, the W3C or
IETF can chime in here and shed light on what the correct process
would be to present this idea for consideration either as a standard
(W3C or IETF) or for browser adoption as open code (Webkit, Mozilla,
Opera, etc.)


> Second, there is a difference between a) implementing the idea in the
> browser engine versus b) implementing it as a part of the application
> executing on the browser engine. The same functionality can be
> achieved by defining a protocol which browsers would implement as a
> part their engine (e.g. using some other available protocol instead of
> WebSockets (e.g. plan old HTTP or SPDY) and threads instead of
> WebWorkers) or by creating web applications where each application
> would implement this protocol itself using application level
> technologies (i.e. the proposed WebSockets and WebWorkers tech). In
> essence, it doesn't matter which technology you use to implement it as
> long as it implements the protocol you define. So, since technologies
> used for implementation are open and available, why would the W3C
> wan't this implemented at the application level versus the browser
> level? Both scenarios require changes to both the server of an
> application and the browser.

It appears to me that implementing it at the application level would
create a richer development environment for web app devs to exploit
the underlying features more directly.

Anyone have any other ideas as to the pros and cons of implementing
this at the browser level or the web app level?


>
> I'm not familiar with NAT traversal or what other novelties IPv6
> introduces other than a broader address space, so I may be wrong when
> saying this but - only by switching from IPv4 to IPv6 will not solve
> this problem. The browser would still be a client initiating
> connections to other network entities, not a server accepting
> connections from those clients. Or as Mike put it: "WebSockets doesn't
> let you open arbitrary ports and listen on them". I'm not getting into
> how hard this is to do, I'm just saying that it's something which is
> necessary.
>

The only familiarity I have with IPv6 are my Apple Airport routers at
home. I know there are different options like node or tunnel in the
settings page. It sounds like that if your computer is connected as a
node, your router is connected as a tunnel and your provider supports
IPv6, then this should all work with IPv6 without lots of
complications.

Given the time it would take to coordinate and execute and idea like
this, I figure that it may be best to develop the idea with IPv6 as
the primary layer 2 protocol.

Someone please correct me if I am mistaken.

>
> I believe Todd from HighScalability will like the idea. It's a
> direction in which lots of people see the Internet/WWW going. I hope
> you didn't get me wrong with my comments - I like your idea of
> distributing the load towards clients.
>

I sent a message to Todd alerting him of this thread, so that he can
take a look and consider blogging about it if it seems interesting to
him.

I didn't get you wrong on the comments. There's tons of brilliant
people participating in the WHAT-WG mailing lists and as I only have
an idea and I don't have the technical knowledge, I figured this would
be the best place to get comments, criticisms and feedback. The more
critical people are about the idea the better. Discussion leads to
better developed ideas.

Received on Friday, 22 January 2010 06:48:08 UTC