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

On Tue, 19 Jan 2010, Andrew de Andrade wrote: > > [...] One of the big problems with these games is the shear amount of > static content that must be delivered via HTTP once the application > becomes popular. In fact, if a game becomes popular overnight, the > scaling problems with this static

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

On Fri, 22 Jan 2010, Andrew de Andrade wrote: > > 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 adoptio

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

On Fri, Jan 22, 2010 at 6:58 AM, Ivan Žužak 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 spe

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

My 2c (as of talking to myself trying to figure out how to do a prototype of this)... 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 t

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

On 22/01/2010, at 07:08, Ivan Žužak wrote: On Fri, Jan 22, 2010 at 03:33, Andrew de Andrade wrote: comments inline - A naive P2P implementation won't provide good throughput or latency because you might end up downloading files from a mobile phone on the other side of the world rather

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

comments inline On Thu, Jan 21, 2010 at 8:24 PM, Mike Hearn wrote: > WebSockets doesn't let you open arbitrary ports and listen on them, > so, I don't think it can be used for what you want. that's my understanding. My question to this is if it is possible to open arbitrary ports and listen in o

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

comments inline On Thu, Jan 21, 2010 at 5:44 PM, Ivan Žužak wrote: > Hi Andrew, > > That's an interesting idea. Here are some of my thoughts: > > As your Google friend noted, I'm wondering why you'd want to implement > this on the HTML5 level, not on the browser (C++) level. Implementing > such a

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

WebSockets doesn't let you open arbitrary ports and listen on them, so, I don't think it can be used for what you want. P2P in general is a lot more complicated than it sounds. It sort of works for things like large movies and programs because they aren't latency sensitive and chunk ordering doesn

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

On Tue, Jan 19, 2010 at 5:31 PM, Melvin Carvalho wrote: > > > On Tue, Jan 19, 2010 at 5:59 PM, Andrew de Andrade > wrote: >> >> I have an idea for a possible use case that as far as I can tell from >> previous discussions on this list has not been considered or at least >> not in the form I prese

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

On Tue, Jan 19, 2010 at 5:59 PM, Andrew de Andrade wrote: > I have an idea for a possible use case that as far as I can tell from > previous discussions on this list has not been considered or at least > not in the form I present below. > > I have a friend whose company produces and licenses onlin

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

I emailed this idea to my friend Patrich Chanezon (, @chanezon) from Google a few weeks ago to get his initial thoughts on the idea as he has been posting lots of links related to web sockets lately. He suggested that the idea would be be implemented at the browser

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

as someone who just listens in and is not technically savvy ...but is helping build interactive television and film production to be browser based... I really want to hear more about this. On Jan 19, 2010 11:59am, Andrew de Andrade wrote: I have an idea for a possible use case that as far a

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

I have an idea for a possible use case that as far as I can tell from previous discussions on this list has not been considered or at least not in the form I present below. I have a friend whose company produces and licenses online games for social networks such as Facebook, Orkut, etc. One of th

Re: [whatwg] Web Sockets URL

On Fri, Dec 4, 2009 at 8:38 PM, Ian Hickson wrote: > On Fri, 4 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: > > On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson wrote: > > > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: > > > > > > > > Currently, the Web Sockets API spec says that the WebSocket.

Re: [whatwg] Web Sockets URL

On Fri, 4 Dec 2009, Fumitoshi Ukai (��~\飼�~V~G�~U~O) wrote: > On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson wrote: > > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: > > > > > > Currently, the Web Sockets API spec says that the WebSocket.URL > > > attribute must just return a value that was passed

Re: [whatwg] Web Sockets URL

On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson wrote: > On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: > > > > Currently, the Web Sockets API spec says that the WebSocket.URL > > attribute must just return a value that was passed to the WebSocket > > constructor. This doesn't match how many other u

Re: [whatwg] Web Sockets URL

On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: > > Currently, the Web Sockets API spec says that the WebSocket.URL > attribute must just return a value that was passed to the WebSocket > constructor. This doesn't match how many other url accessors work, and > consequentially, it doesn't match wh

Re: [whatwg] Web sockets and existing HTTP stacks

On Tue, 17 Nov 2009, Christian Biesinger wrote: > > Is it intentional that it is impossible to implement this spec over an > existing HTTP stack, as currently specified? Only to the same extent that it is "intentional" that it's impossible to implement Telnet or SSH over an existing HTTP stack.

[whatwg] Web Sockets URL

Currently, the Web Sockets API spec says that the WebSocket.URL attribute must just return a value that was passed to the WebSocket constructor. This doesn't match how many other url accessors work, and consequentially, it doesn't match what currently happens in WebKit. I think it makes mor

Re: [whatwg] Web sockets and existing HTTP stacks

On Tue, Nov 17, 2009 at 11:02 PM, Christian Biesinger wrote: > Hi, > > so I was reading the web sockets spec as well as a Firefox patch to > implement it. [...] It's been suggested that I resend my comments to h...@ietf, so I did. Should appear at http://www.ietf.org/mail-archive/web/hybi/current

[whatwg] Web sockets and existing HTTP stacks

Hi, so I was reading the web sockets spec as well as a Firefox patch to implement it. Is it intentional that it is impossible to implement this spec over an existing HTTP stack, as currently specified? In particular, due to the strict requirements on the headers to send, it seems like you can't r

Re: [whatwg] Web Sockets API — send() with clos ed connections

On Tue, Oct 27, 2009 at 01:17, Ian Hickson wrote: > The connection might get closed at any point, e.g. between the script > checking if the connection might be closed and the script calling the > send() method. Because of this, if we raised an exception when the > connection was closed, we'd run

Re: [whatwg] Web Sockets API — send() with clos ed connections

On Sun, 25 Oct 2009, Avi Flax wrote: > > Just one thing struck me as odd: calling send(data) on a WebSocket > whose readyState is CONNECTING raises an INVALID_STATE_ERR exception, > but calling send(data) on a WebSocket whose readyState is CLOSED does > not raise an exception; it merely returns

[whatwg] Web Sockets API — send() with clos ed connections

My apologies if this has been answered before; I searched the list and found some similar questions but no answers. I just read the latest draft of this API, and it's great, very exciting. Just one thing struck me as odd: calling send(data) on a WebSocket whose readyState is CONNECTING raises an

Re: [whatwg] Web Sockets

> > 3.) If the resulting absolute URL has a component, then let > port be that component's value; otherwise, if secure is false, let > port be 81, otherwise let port be 815. > I found this in rfc2817 section 1: The historical practice of deploying HTTP over SSL3 [3] has distinguished the

Re: [whatwg] Web Sockets

3.) If the resulting absolute URL has a component, then let port be that component's value; otherwise, if secure is false, let port be 81, otherwise let port be 815. No, no, no! Don't let paranoia override common sense. Not all websocket applications will have the luxury to run on these por

Re: [whatwg] Web Sockets

Philipp Serafin wrote: Asynchronous: Requests and responses can be pipelined, meaning requests and responses can be transmitted simultaneously and are queued. I think the problem is that this definition of "asynchronous" is very narrow. Yes, you don't need to wait for a request to finis

Re: [whatwg] Web Sockets

On Tue, Jul 22, 2008 at 6:47 AM, Shannon <[EMAIL PROTECTED]> wrote: > wait for connection; > receive persistent connection request; > pass request body to service; > response = read from service; > response_length = length of response; > send Content-Length: $response_length; > send $response > cl

Re: [whatwg] Web Sockets

In order to understand this issue better I did some preliminary research into how HTTP and common implementations currently support the five primary requirements of the WebSocket/TCPSocket proposal; namely persistence, asynchronism, security, shared hosting and simplicity. After reading http://

Re: [whatwg] Web Sockets

On Tue, 22 Jul 2008, Frode Børli wrote: > > 1. Allow pure TCPSocket using this method: var s = new > TCPSocket("/tcpsocket.xml"); > > The tcpsocket.xml-file must have a structure similar to this: > > > hostname/ip-address > portnumber > * > > > [...] port: any port We can't do this, bec

Re: [whatwg] Web Sockets

I have some feedback based on the discussions i participated in earlier. Since I am on vacation I cannot give a proper proposal but I think the following should be considered: 1. Allow pure TCPSocket using this method: var s = new TCPSocket("/tcpsocket.xml"); The tcpsocket.xml-file must have a s

Re: [whatwg] Web Sockets

On Mon, 14 Jul 2008, Honza Bambas wrote: > > I am just concern about the way the protocol is specified. When I read > the notes it is obvious the communication is actually an HTTP > communication. Let's say I am a browser developer. Let's say I have to > enhance my already fully armed browser wi

Re: [whatwg] Web Sockets

Ian Hickson wrote: Many years ago I wrote a draft for how to do full-duplex communication from a Web page. Over the years we've received much feedback on this TCPConnection API. I've now completely rewritten the relevant section and given it a new name, Web Sockets: http://www.whatwg.org/

Re: [whatwg] Web Sockets

TECTED] On Behalf Of Brady Eidson Sent: den 7 juli 2008 22:50 To: Mike Ter Louw Cc: whatwg; Ian Hickson Subject: Re: [whatwg] Web Sockets On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote: Joking aside, should a blocking read/recv call be made available? In some cases additional lag may be an acce

Re: [whatwg] Web Sockets

> Sent: den 7 juli 2008 22:50 > To: Mike Ter Louw > Cc: whatwg; Ian Hickson > Subject: Re: [whatwg] Web Sockets > > On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote: > > Joking aside, should a blocking read/recv call be made available? > > In some cases a

Re: [whatwg] Web Sockets

On Mon, 7 Jul 2008, Mike Ter Louw wrote: > > Joking aside, should a blocking read/recv call be made available? In > some cases additional lag may be an acceptable compromise for > maintaining the JavaScript call stack until a response arrives. Blocking I/O is a non-starter on the main thread.

Re: [whatwg] Web Sockets

On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote: Ian Hickson wrote: Bringing in Apache as a library is a serious cost compared to WebSocket whose handshake can be implemented in a dozen lines of perl. Careful, there are probably someone out there that will take this as a challenge to i

Re: [whatwg] Web Sockets

Ian Hickson wrote: Bringing in Apache as a library is a serious cost compared to WebSocket whose handshake can be implemented in a dozen lines of perl. Careful, there are probably someone out there that will take this as a challenge to implement Apache in a dozen lines of Perl! :P Joking as

Re: [whatwg] Web Sockets

On Sun, 6 Jul 2008, Charl van Niekerk wrote: > > I'm very happy, just one small concern so far. Please excuse the typical > "African" issue but over here the networks are particularly terrible and > this does affect us quite badly. I would like to be able to determine > whether a connection has

Re: [whatwg] Web Sockets

On Sun, Jul 6, 2008 at 11:18 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#network I'm very happy, just one small concern so far. Please excuse the typical "African" issue but over here the networks are particularly terribl

[whatwg] Web Sockets

Many years ago I wrote a draft for how to do full-duplex communication from a Web page. Over the years we've received much feedback on this TCPConnection API. I've now completely rewritten the relevant section and given it a new name, Web Sockets: http://www.whatwg.org/specs/web-apps/curre