> 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-dev@googlegroups.com.
> To unsubscribe from this group, send email to jquery-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.