Hi Martín
I Recompensate your questions politely, but, I do not have time.
Quick 3 points:
(2) "Close open sockets on unload" is handled by the UA
- Currently Chrome 4.0.266.0 isn't close on unload. :-(
(3) "Keep up a heartbeat with the server"
is protocol-dependent and I'm not sure is even necessary,
- If (Keep-Alive is On) Close is delayed by Timeout of
server.
else if (Keep-Alive is Off)
if (you do not send anything)
Close is delayed by Timeout of
server.
(4) depends on what you're trying to do with data coming out of
the
socket (and data sanitation should be handled by the server in most
cases).
- Yes, I think so too SHOULD be "handled by the server".
But, this is jQuery's style.
@ see jQuery v1.4 line 4586
On Jan 20, 2:37 pm, Sidney San Martín <s...@sidneysm.com> wrote:
> If I'm reading you correctly, jQuery support for Web Sockets would be:
>
> 1. Feature detection through jQuery.support
> 2. Close open sockets on unload
> 3. Keep up a heartbeat with the server
> 4. Filter JavaScript from incoming data
> 5. jQuery-like API for sending and receiving on sockets.
>
> (1) would make sense only if there were other support in jQuery, (2) is
> handled by the UA, (3) is protocol-dependent and I'm not sure is even
> necessary, (4) depends on what you're trying to do with data coming out of
> the socket (and data sanitation should be handled by the server in most
> cases). (5) is a different question entirely.
>
> I've definitely seen posts pop up on discussion boards and mailing lists
> asking "how can I rewrite such-and-such JavaScript in jQuery?" While
>
> if (typeof WebSocket === 'object') {
> socket = new WebSocket('ws://example.com');
> socket.onmessage = handleMessage;
> }
>
> doesn't fit in with existing jQuery code as well as
>
> if ($.support.sockets) {
> socket = $.socket('ws://example.com').receive(handleMessage);
> }
>
> should anyone care? I don't know. The jQuery object always represents a
> collection of DOM elements because jQuery has always been about talking to
> the DOM.
>
> On the other hand, with JSON-encoded responses $.ajax succeeds in turning
> XMLHTTPRequest into a tube that you can shove objects and arrays into and get
> same back. That's solidly outside DOM territory but is a well-worn jQuery
> feature. Automagic response parsing into native types could work for Web
> Sockets as well.
>
> There are more wild and interesting things that *could* be done by
> abstracting a bit — like the framework maintaining a single socket to your
> app and triggering custom event handlers based on metadata in messages — but
> it's still way to early to suggest putting any of that in jQuery proper. If
> you want to live on the bleeding edge, write some code. Sanding down the API
> can come once we know what the heck we want it to look like.
>
> On Jan 19, 2010, at 10:00 PM, tato wrote:
>
> > Hi Friesen
>
> > Your code is yes. Please try following.
>
> > <input type="text" id="test" value="hello!">
> > <button onclick="ws.send(document.getElementById('test').value)">send</
> > button>
>
> > <script>
> > var ws = new WebSocket("ws://bloga.jp:80/echo");
> > ws.onmessage = function(msg) {
> > alert(msg.data)
> > };
> > </script>
>
> > You send 'hi!', You'll receive 'hi!'
> > If You send 'Goodbye', then see TCP Packet, You'll receive
> > Connection: close
>
> > eg.
>
> > GET /echo HTTP/1.1･･Upgrade: WebSocket･･Connection: Upgrade･･Host:
> > bloga.jp･･Origin: file://･･････
> > tcp 202.215.119.36:80 > 192.168.1.10:1032
> > ( omit )
> > tcp 192.168.1.10:4964 > 202.215.119.36:80
> > ･hi!････････････････････････････････････････････････････････
> > tcp 202.215.119.36:80 > 192.168.1.10:4964
> > ･hi!････････････････････････････････････････････････････････
> > tcp 192.168.1.10:4942 > 202.215.119.36:80
> > ･Goodbye････････････････････････････････････････････････････
> > tcp 202.215.119.36:80 > 192.168.1.10:4942
> > ･Goodbye････････････････････････････････････････････････････
> > tcp 202.215.119.36:80 > 192.168.1.10:4942
> > HTTP/1.1 200 OK･･Date: Wed, 20 Jan 2010 00:16:04 GMT･･Server: Apache/
> > 2.2.12 (Ubuntu)･･Content-Length: 0･･Connection: close･･Cont
> > ent-Type: text/plain････････････････････････････････････････
>
> > This "ws://bloga.jp:80/echo" is a echo server of mod_pywebsocket's
> > sample.
> > I have not checked Origin, It will work. if connected to the Internet.
> > Even if the local disk.
>
> > Well, There are three ways
>
> > 1.Min support
> > 2.Partial support
> > 3.Full support
>
> > I think, case 3:
> > create $.websocket like $.ajax
> > onunload close,keep alive heatbeat,/<script(.|\s)*?\/
> > script>/g, "",nosupport flag etc...
> > now, we are looking for tips
> > case 2:
> > Some methods into the $ or $.fn
> > Perhaps many variations
> > case 1:
> > only create ws object
> > eg.
> > $.extend({
> > ws : function (url){
> > if(WebSocket)return new WebSocket(url);
> > }
> > })
> > but, This is so useless, but in the namespace.
>
> >> WS isn't HTTP
>
> > Yes, it is. Upgrade: WebSocket from HTTP GET.
>
> > eg.
>
> > tcp 192.168.1.4:1715 > 202.215.119.36:80
> > GET /echo HTTP/1.1･･Upgrade: WebSocket･･Connection: Upgrade･･Host:
> > bloga.jp･･Origin: file://････････････････････････････････････
>
> >> You do realize that WS cannot be used in most shared hosting setups?
>
> > When I started my JavaScript (1996), AddType application/x-
> > javascript .js even cannot be used in shared hosting. But, in a few
> > years, everywhere
>
> > I do not know the future, however, if it was useful, I think that
> > spread quickly. And perhaps there are advantages to shared hosting
> > sever. Because only connection for the server load low. Last week, 40
> > in connection load average is 0.00 at Atom CPU Server. Of course a lot
> > more testing is required.
>
> > Thanx
>
> > 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
>
> ...
>
> read more »
>
> smime.p7s
> 8KViewDownload
--
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.
