WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets. - jQuery Development

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
Received-SPF: pass (google.com: domain of nadir.seen.f...@gmail.com designates 209.85.216.183 as permitted sender) client-ip=209.85.216.183;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=AjYNqIxtubj8A2PIDKU1P7tUR8xjFn9LazCzKx/fR6AGACIMrtB6zcwN+hH+TVT5Sl
         C3mxiMPbw8LNJrxa165VBlgqF0d2vV8FlyKS0egjRCkkji/wODapaLy4EJH6jQysP0Vx
         ROF/A9v9HOE9OSwlglvSaMvsiVlNp/+2rBK00=
Message-ID: <4B573A57.9000...@gmail.com>
Date: Wed, 20 Jan 2010 09:16:07 -0800
From: Daniel Friesen <nadir.seen.f...@gmail.com>
Reply-To: gm...@danielfriesen.name
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 ThunderBrowse/3.2.1.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: jquery-dev@googlegroups.com
Subject: Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to
 support of jQuery for WebSockets.
References: <bf504415-ea36-4ca0-8179-e8b5886e4...@c29g2000yqd.googlegroups.com> 	<4B549A16.3010...@gmail.com> <deff46d6-bddd-4b29-bb30-6c9516172...@l30g2000yqb.googlegroups.com> 	<4B55F569.6050...@gmail.com> <e81ce35e-4e09-4e0c-838e-cd43ca25d...@b2g2000yqi.googlegroups.com>
In-Reply-To: <e81ce35e-4e09-4e0c-838e-cd43ca25d...@b2g2000yqi.googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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]
>>
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
