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 am, 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 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.
