                                                                                                                                                                                                                                                                
Received-SPF: neutral (google.com: 209.85.210.155 is neither permitted nor denied by best guess record for domain of t...@game.gr.jp) client-ip=209.85.210.155;
MIME-Version: 1.0
Date: Wed, 20 Jan 2010 09:55:29 -0800 (PST)
In-Reply-To: <4B573A57.9000002@gmail.com>
References: <bf504415-ea36-4ca0-8179-e8b5886e4b40@c29g2000yqd.googlegroups.com> 
	<4B549A16.3010206@gmail.com> <deff46d6-bddd-4b29-bb30-6c9516172793@l30g2000yqb.googlegroups.com> 
	<4B55F569.6050906@gmail.com> <e81ce35e-4e09-4e0c-838e-cd43ca25d842@b2g2000yqi.googlegroups.com> 
	<4B573A57.9000002@gmail.com>
User-Agent: G2/1.0
Message-ID: <c17301d1-866b-4fdf-8fd0-c1d0800140be@y23g2000yqm.googlegroups.com>
Subject: Re: WebSockets is very faster than xhr. I hope to support of jQuery 
	for WebSockets.
From: tato <t...@game.gr.jp>
To: jQuery Development <jquery-dev@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On this sample,
$(Selector).wsload("URL",callback) is like $(Selector).load
("URL",callback)

but, not the same.

Data of  "load it into a node" is not a single message.
Display changes automatically. Change over time and display data being
sent to


On Jan 21, 2:16=C2=A0am, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
> Huh? You want to open a WebSocket connection not widely supported yet in
> order to accept a single message and load it into a node, abusing a
> feature for something it's not meant for, requiring extra unnecessary
> work on the server, and completely ditching the browser's http caching
> ability?
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> tato wrote:
> > Hi =C2=A0Friesen
> > I Had forgotten to answer this question
>
> >> How much shorter can jQuery possibly make that?
>
> > Of course, there are a variety of writing, a sample of one
>
> > $("# board")
> > =C2=A0 =C2=A0 .wsload("ws://example.com")
> > =C2=A0 =C2=A0 .css({color: "red"})
>
> > Sample
> >http://bloga.jp/ws/jq/wsload/b01.htm
>
> > On Jan 20, 3:09 am, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
>
> >> tato wrote:
>
> >>> Thax,
>
> >>> First the excuses. This is a discussion about the future.
> >>> However, this future is in front of us.
>
> >>> Browser's between incompatibility in ajax was need JS Library /
> >>> jQuery, and was very helpful. It is, I agree.
>
> >>> But even if there is compatibility, jQuery support of xhr is useful.
>
> >>> Future browser with WebSockets implemented, I want compatibility
> >>> between them.
> >>> But I think, even if there is compatibility, jQuery support of ws is
> >>> useful too. Rather less code ;-)
>
> >> Less code?
> >> var ws =3D new WebSocket("ws://example.com");
> >> ws.onmessage =3D function(msg) {
> >> =C2=A0 =C2=A0 // ...
>
> >> };
>
> >> How much shorter can jQuery possibly make that?
>
> >>>> WS is a bi-directional non-HTTP socket which needs a dedicated serve=
r.
>
> >>> It's non-HTTP, but it's on-HTTP too.
> >>> I think, WS is a real bi-directional on-HTTP shares available socket,
> >>> isn't it?
>
> >>> I tested on mod_pywebsocket, that is a Web Socket extension for Apach=
e
> >>> HTTP Server. IETF specification is, The Web Socket default port is 80
> >>> or 443.
>
> >>>http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44#sectio.=
..
> >>>http://code.google.com/p/pywebsocket/
> >>>http://blog.chromium.org/2009/12/web-sockets-now-available-in-google..=
..
>
> >> WS' handshake is HTTP-like. The only "HTTP" in WS is a handshake that
> >> immediately upgrades the connection to the WebSocket protocol leaving
> >> HTTP behind.
> >> WS isn't HTTP, it completely breaks the request-response model of HTTP=
,
> >> it just encapsulates itself in HTTP. If WebSockets were HTTP websocket
> >> urls would be http:// not ws://
> >> The purpose of the HTTP handshake iirc is primarily so that existing
> >> load balancing technologies, proxy servers like varnish, etc... meant
> >> for http can still be used (in pipe mode ignoring contents mostly) and
> >> also so WS doesn't require another port which is default-blocked in mo=
st
> >> cases.
>
> >> You do realize that WS cannot be used in most shared hosting setups?
> >> Most shared hosts use apache, which as I recall buffers http
> >> requests/responses meaning WS won't work on the other side, and the
> >> users obviously can't install new modules. To use WS you need some sor=
t
> >> of VPS, Cloud server, dedicated server, etc... Anything but a shared h=
ost.
> >> That there is likely a good portion of the jQuery userbase.
>
> >>>> WS is simply "faster" because it doesn't need all the extra cruft in=
 a
>
> >>> HTTP call
>
> >>> I think so too. XHR requires a lot of headers, and many connections.
> >>> WS is Handshake header 'GET / demo HTTP/1.1 ...', only once.
>
> >>> WS is so friendly for network and servers. Moreover, "faster" on HTTP=
.
>
> >>> With Best regards, for into the good future
>
> >>> On 1=E6=9C=8819=E6=97=A5, =E5=8D=88=E5=89=8D2:27, Daniel Friesen <nad=
ir.seen.f...@gmail.com> wrote:
>
> >>>> I don't like the idea. At this point there is no reason to believe t=
hat
> >>>> any browser with WebSockets implemented will break spec and need a
> >>>> compatibility layer (the primary reason jQuery has ajax). I don't se=
e
> >>>> how jQuery could add any functionality to WebSockets, the api is alr=
eady
> >>>> quite nice, not to mention there are a large number of calls and par=
ts
> >>>> to the api, so there would be a pile of jQuery code just matching up=
 the
> >>>> api to make calls you could make without jQuery at all.
>
> >>>> In any case, comparing WS to XHR in terms of speed is completely
> >>>> pointless. XHR is a way to make a HTTP call from JS. WS is a
> >>>> bi-directional non-HTTP socket which needs a dedicated server. They =
have
> >>>> completely different purposes and use cases, speed is irrelevant to =
a
> >>>> comparison. WS is simply "faster" because it doesn't need all the ex=
tra
> >>>> cruft in a HTTP call and it's an open dedicated connection between t=
he
> >>>> browser and the server that doesn't close after every message.
>
> >>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.na=
me]
>
> >>>> ...
>
> >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name=
]