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 ;-)

> WS is a bi-directional non-HTTP socket which needs a dedicated server.

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 Apache
HTTP Server. IETF specification is, The Web Socket default port is 80
or 443.

http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44#section-1.5
http://code.google.com/p/pywebsocket/
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html

> 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月19日, 午前2:27, Daniel Friesen <nadir.seen.f...@gmail.com> wrote:
> I don't like the idea. At this point there is no reason to believe that
> any browser with WebSockets implemented will break spec and need a
> compatibility layer (the primary reason jQuery has ajax). I don't see
> how jQuery could add any functionality to WebSockets, the api is already
> quite nice, not to mention there are a large number of calls and parts
> 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 extra
> cruft in a HTTP call and it's an open dedicated connection between the
> browser and the server that doesn't close after every message.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
>
>
> tato wrote:
> > WebSockets is very faster than xhr. I think jQuery had better support
> > WebSockets in Core.
>
> > The following Samples of text mining are speed comparison, WS vs  XHR.
> > at my Office(same bloga.jp), the speed difference was following.
>
> > /* need Chrome4.0.249.0 +  or Safari nightly */
>
> >http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html
> > case websocket (pipeline) 156 msec
> > case XML HTTP request (parallel Ajax) 4978 msec
> > # 31-fold
>
> >http://bloga.jp/ws/jq/wakachi/mecab/ruby.html
> > case websocket (pipeline) 339 msec
> > case XML HTTP request (parallel Ajax) 1506 msec
> > # 4-fold
>
> > (http://code.google.com/p/websocket-sample/)
>
> > eg.
> > W3C The Web Sockets API
> >http://dev.w3.org/html5/websockets/
> > IETF The Web Socket protocol
> >http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-44
>
> > My jQuery plugin for WS
> >http://plugins.jquery.com/project/ws
-- 
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to 
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.


Reply via email to