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.
