Hi  Friesen
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")
    .wsload("ws://example.com")
    .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 = new WebSocket("ws://example.com");
> ws.onmessage = function(msg) {
>     // ...
>
> };
>
> How much shorter can jQuery possibly make that?
>
> >> 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#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 most
> 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 sort
> of VPS, Cloud server, dedicated server, etc... Anything but a shared host.
> 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月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]
>
> >> ...
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
-- 
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