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.
