[jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
@Tato, WebSocket is specified by Google Inc, and (surpise?) it works already in CHROME. Google has a plan to have 100% HTML5 compliant browser to act as the only front end to its OS. In that context WebSockets are a necessity. And (surprise?) CHROME OS will be talking only with Goggle servers which will support WebSockets. This is not rendering WebSokcets as useless, It is only showing you the reality in which MSFT, Mozilla and Opera can be less than enthusiastic about WebSockets. Also, Web Sockets is two standalone specifications, and no longer part of HTML5 ... Hope this helps -- DBJ On Jan 19, 4:25 am, tato t...@game.gr.jp 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 ;-) 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 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.
[jquery-dev] Re: Binding change on an select though .live() doesn't seem to work in IE using jQuery 1.4
On Jan 18, 11:42 pm, alexander farkas a.farkas...@googlemail.com wrote: The code explained above will fix this issue. Great, and John has now committed the fix. Let's hope 1.4.1 is not too far away! ;) -- 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.
[jquery-dev] Trouble with ui datepicker and ie security zones
I run my site with ui datepicker at localhost in IE with security params - internet zone, high level(ask to enable javascript). I add localhost to trusted sites. When datepicker shows (_updateDatepicker function call), IE ask me to enable javascript - it`s not correct behaviour. Generated datepicker div contains js functions call and jquery-1.3.2.js first of all sets div.innerHTML and then fragment.appendChild(). http://karma.nucleuscms.org/item/101 has decision that innerHTML must be after appendChild. Is it bug jquery? How can I solve this problem? -- 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.
Re: [jquery-dev] Re: Binding change on an select though .live() doesn't seem to work in IE using jQuery 1.4
Great, and John has now committed the fix. Let's hope 1.4.1 is not too far away! ;) It'll be out by Friday. --John -- 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.
[jquery-dev] Related to autocomplete plugin query
Hi, I am using autocomplete plug-in of jquery. I have a data set as below: DATA STRING | ID foo bar | 1 When I search for say, “foo” OR “foo ba” OR “bar” it gives me proper result. But when I extend my search string from ‘bar’ to say, ‘bar fo’ than result disappears. Basically I am trying to make autocompletor similar to Search Box on FaceBook. Any idea or pointer would be of great help. Thanks in advance Amit -- 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.
Re: [jquery-dev] Trouble with ui datepicker and ie security zones
That isn't really something that we can globally assure. We frequently create disconnected nodes and fragments before eventually inserting them into the document. Not to mention that delaying the insertion of the HTML will cause a double page reflow to occur, slowing things down even further. --John On Tue, Jan 19, 2010 at 3:16 AM, anemon anemo...@gmail.com wrote: I run my site with ui datepicker at localhost in IE with security params - internet zone, high level(ask to enable javascript). I add localhost to trusted sites. When datepicker shows (_updateDatepicker function call), IE ask me to enable javascript - it`s not correct behaviour. Generated datepicker div contains js functions call and jquery-1.3.2.js first of all sets div.innerHTML and then fragment.appendChild(). http://karma.nucleuscms.org/item/101 has decision that innerHTML must be after appendChild. Is it bug jquery? How can I solve this problem? -- 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. -- 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.
Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
On 1/19/10 4:52 AM, DBJDBJ wrote: @Tato, WebSocket is specified by Google Inc, and (surpise?) it works already in CHROME. This isn't quite true. WebSockets are being specced both in the W3C and WHATWG, and is not a Google product despite their early implementation. Google has a plan to have 100% HTML5 compliant browser to act as the only front end to its OS. In that context WebSockets are a necessity. And (surprise?) CHROME OS will be talking only with Goggle servers which will support WebSockets. This is not rendering WebSokcets as useless, It is only showing you the reality in which MSFT, Mozilla and Opera can be less than enthusiastic about WebSockets. Mozilla has made some good progress towards an implementation. You can follow this BugZilla ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=472529 The WHATWG wiki also states that there is work underway for Safari/Webkit--without a linked ticket: http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers#Web_Sockets Also, Web Sockets is two standalone specifications, and no longer part of HTML5 ... http://www.w3.org/TR/websockets/ http://dev.w3.org/html5/websockets/ http://www.whatwg.org/specs/web-apps/current-work/complete.html#network [snip] -Mike -- 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.
[jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
WebSockets are usefull if you need some light, realtime interaction between the server and the client, which is still a pretty rare usecase for the most of us. If you are about to build the next Gmail, Docs or Wave, I think you can afford to craft a jQuery plugin to add some synthatic sugar and magic to websockets manipulation, and fallbacks for unsupported browsers. I'd love to get pinged with a link to this future plugin :) On Jan 19, 4:05 pm, Mike Taylor miketa...@gmail.com wrote: On 1/19/10 4:52 AM, DBJDBJ wrote: @Tato, WebSocket is specified by Google Inc, and (surpise?) it works already in CHROME. This isn't quite true. WebSockets are being specced both in the W3C and WHATWG, and is not a Google product despite their early implementation. Google has a plan to have 100% HTML5 compliant browser to act as the only front end to its OS. In that context WebSockets are a necessity. And (surprise?) CHROME OS will be talking only with Goggle servers which will support WebSockets. This is not rendering WebSokcets as useless, It is only showing you the reality in which MSFT, Mozilla and Opera can be less than enthusiastic about WebSockets. Mozilla has made some good progress towards an implementation. You can follow this BugZilla ticket:https://bugzilla.mozilla.org/show_bug.cgi?id=472529 The WHATWG wiki also states that there is work underway for Safari/Webkit--without a linked ticket:http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers#Web_Sockets Also, Web Sockets is two standalone specifications, and no longer part of HTML5 ... http://www.w3.org/TR/websockets/http://dev.w3.org/html5/websockets/http://www.whatwg.org/specs/web-apps/current-work/complete.html#network [snip] -Mike -- 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.
Re: [jquery-dev] slideToggle() bug?
But it doesn't work in IE, which really does not like these sorts of manipulations of table rows. I don't know if there's an easy fix to that. IE needs you to hide all the TD elements in order to actually hide a TR element. -Dan -- 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.
Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
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#section-1.5
http://code.google.com/p/pywebsocket/
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html
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.
[jquery-dev] Namespaces custom live events broken in 1.4
It seems that something has changed regarding namespaced live()
events. Looks broken to me:
Test case:
html
head
script type=text/javascript src=/js/jquery.js/script
script type=text/javascript
$(document).ready(function() {
$('#mydiv').bind('click', function(ev) { console.log(click); });
$('#mydiv').bind('click.goodbye', function(ev) { console.log
(click.goodbye); });
$('#mydiv').bind('goodbye', function(ev) { console.log
(goodbye); });
$('#mydiv').bind('hello.goodbye', function(ev) { console.log
(hello.goodbye); });
$('#mydiv').trigger('click');
$('#mydiv').trigger('click.goodbye');
$('#mydiv').trigger('goodbye');
$('#mydiv').trigger('hello.goodbye');
});
/script
/head
body
div id=mydivMy DIV/div
/body
/html
1.3.2 results (as expected):
click
click.goodbye
click.goodbye
goodbye
hello.goodbye
1.4 results (BAD):
click
click
goodbye
1.4 results ( replacing live() with bind() ):
click
click.goodbye
click.goodbye
goodbye
hello.goodbye
--
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.
[jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
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
Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
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
