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

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Sidney San Martín
IIRC the jQuery team said that Web Socket features aren't being
considered right now because very few browsers support them, and
equally few website take or plan to take advantage of them in the near
future. It's not worth the space to put support in every copy of
jQuery.

jQuery is also most useful when browsers' APIs are lacking or
inconsistent. I don't think we know yet if Web Sockets even need its
help.

If they do, you or someone else should write a plugin, and if the Web
Sockets situation changes, support will be baked in.

On Mon, Jan 18, 2010 at 6:01 AM, tato <[hidden email]> 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 [hidden email].
> To unsubscribe from this group, send email to [hidden email].
> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

tato-4
Well,  I $.ws.send("my hope into the future")  :-)

Still, It's ridiculously fast.
more asynchronous javascript + sockets
It's so just Cloud.

On Jan 19, 12:37 am, Sidney San Martín <[hidden email]> wrote:

> IIRC the jQuery team said that Web Socket features aren't being
> considered right now because very few browsers support them, and
> equally few website take or plan to take advantage of them in the near
> future. It's not worth the space to put support in every copy of
> jQuery.
>
> jQuery is also most useful when browsers' APIs are lacking or
> inconsistent. I don't think we know yet if Web Sockets even need its
> help.
>
> If they do, you or someone else should write a plugin, and if the Web
> Sockets situation changes, support will be baked in.
>
> On Mon, Jan 18, 2010 at 6:01 AM, tato <[hidden email]> 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 [hidden email].
> > To unsubscribe from this group, send email to [hidden email].
> > For more options, visit this group athttp://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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Daniel Friesen-2
In reply to this post by tato-4
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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

tato-4
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#section-1.5
http://code.google.com/p/pywebsocket/
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html

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


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

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


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

tato-4
Hi DBJ Thanx

I did not know about Google's plans. And, CHROME OS currently does not
have much interest. On the web, we have free, and will be talking to
any WS-server,  Allow Origin.

If there is benefit to Google, or jeopardizes the benefits of the
user?
Google may also have the advantage, the benefits of users think there
are more than that.

Today, I tried the text-mining samples Seattle - between Tokyo.
http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html
WS 606 msec
XHR 31863 msec!

It's ridiculously fast, don't you?

Indeed, only XHR is good enough? For us.
It can end in 0.6 seconds, you really pick the 30 seconds?

# Now, Sfari-nightly support WebSockets
http://nightly.webkit.org/

On Jan 19, 6:52 pm, DBJDBJ <[hidden email]> wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Mike Taylor-15
In reply to this post by DBJDBJ
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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

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


Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Daniel Friesen-2
In reply to this post by tato-4
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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

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


Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Sidney San Martín
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
> To unsubscribe from this group, send email to [hidden email].
> For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
>
>


smime.p7s (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

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


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

tato-4
In reply to this post by Daniel Friesen-2
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

DBJDBJ
In reply to this post by Mike Taylor-15
1.
Are WebSockets officially part of HTML5 ? Mike I can see the specs,
yes. But this is definitely would be the  most questionable HTML5
detail, it seems to me?
This almost introduces synhcronous two-way sockets in the middle of
totaly async www infrastructure... There is no amount of fibre today,
which would be enough for all www users to connect to www with a
single WebSocket from their browsers. That much is obvious. WebSockets
require additional server-side configuration and setup which (for
example) Appache (out of the box) does not support today. Neither does
IIS, it that matters.
2.
On each and every WebSockets spec, I see no other author of the spec
but Ian Hickson,  Google Inc. Which strikes me as odd? Is he (and
Google Inc) such a capable and unqestionable WebSockets, www leader ?
3.
This very simple question is a very big question for WebSockets
future : Who and where and why, will provide full WebSockets
functionality on the server side ?
( Google will because of CHROME OS ).

--DBJ

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Marco Pivetta
Why are you bothering about HTTP servers if we are talking about WebSockets and _NOT_ HTTP? :)
I think WebSockets are almost necessary for the future of the web. I've been developing some addons for Firefox in the past months, and wanted to put an XMPP/Jabber chat client/UI (some kind of server-client interaction based on XMPP) in my extension to let users communicate faster and be everytime updated on what's going on. I tried to use HTTP binding but it was a disaster! Too many headers, overhead and slow transfers! My Apache 2.2 was melting with just 2000 users (just working as a proxy)! I have a single server, not a cluster nor a load balancer. I had to relay on XMPP4Moz (an extension built upon Gecko XPCOM APIs) and I used a socket. -problem (almost) solved-
It really helped a lot! Also with my super-slow-UMTS-usb-dongle (thank you H3G -.-'' )!
I would really like to see Facebook, Google and also my own servers being using websockets (J2EE, ever heard of it? PHP/CGI is not THE solution).
So why not spreading this technology with some $.ws("url",{/*stuff*/}); ?
Even if it works only on chrome, bringing such a great improvement to jQuery could force the web developers and web browsers to move forward (also if just a bit)!
jQuery is not just a toolbox, it is becoming some kind of "standard"! Let's move it forward to force others to follow it! :)
Is it science-fiction for you? I hope not...

2010/1/20 DBJDBJ <[hidden email]>
1.
Are WebSockets officially part of HTML5 ? Mike I can see the specs,
yes. But this is definitely would be the  most questionable HTML5
detail, it seems to me?
This almost introduces synhcronous two-way sockets in the middle of
totaly async www infrastructure... There is no amount of fibre today,
which would be enough for all www users to connect to www with a
single WebSocket from their browsers. That much is obvious. WebSockets
require additional server-side configuration and setup which (for
example) Appache (out of the box) does not support today. Neither does
IIS, it that matters.
2.
On each and every WebSockets spec, I see no other author of the spec
but Ian Hickson,  Google Inc. Which strikes me as odd? Is he (and
Google Inc) such a capable and unqestionable WebSockets, www leader ?
3.
This very simple question is a very big question for WebSockets
future : Who and where and why, will provide full WebSockets
functionality on the server side ?
( Google will because of CHROME OS ).

--DBJ

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.






--
Marco Pivetta - Ocramius Aethril
Standard Ogame Project - StOgame
http://www.stogame.net
Making Ogame a better place...
Sent from Padova, Veneto, Italia
--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Mike Taylor-15
In reply to this post by DBJDBJ
On 1/20/10 5:44 AM, DBJDBJ wrote:
1.
Are WebSockets officially part of HTML5 ? Mike I can see the specs,
yes. But this is definitely would be the  most questionable HTML5
detail, it seems to me?
  
They used to be part of html5, but now are just lumped in the following group:

"Features that are not currently in this document that were in the past considered part of HTML5, or that were never part of HTML5 but have been referred to as part of HTML5 in the media."

This almost introduces synhcronous two-way sockets in the middle of
totaly async www infrastructure... There is no amount of fibre today,
which would be enough for all www users to connect to www with a
single WebSocket from their browsers. That much is obvious. WebSockets
require additional server-side configuration and setup which (for
example) Appache (out of the box) does not support today. Neither does
IIS, it that matters.
2.
On each and every WebSockets spec, I see no other author of the spec
but Ian Hickson,  Google Inc. Which strikes me as odd? Is he (and
Google Inc) such a capable and unqestionable WebSockets, www leader ?
  
He is the editor, yes.
3.
This very simple question is a very big question for WebSockets
future : Who and where and why, will provide full WebSockets
functionality on the server side ?
( Google will because of CHROME OS ).
  
Cool.
--DBJ
  


--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

tato-4
If you want to see the document
http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5?

1 Introduction
  1.1 Is this HTML5?

   Features that are not currently in this document that were in the
past
   considered part of HTML5, or that were never part of HTML5 but have
   been referred to as part of HTML5 in the media, include:

     * Web Workers
     * Web Storage
     * Web Sockets API
     * Web Sockets protocol
     * Server-sent Events
     * Web SQL Database
     * Geolocation API
     * SVG
     * MathML
     * XMLHttpRequest


But, It is a Classification.
No change, the usefulness is.



On Jan 21, 12:02 am, Mike Taylor <[hidden email]> wrote:

> On 1/20/10 5:44 AM, DBJDBJ wrote:> 1.
> > Are WebSockets officially part of HTML5 ? Mike I can see the specs,
> > yes. But this is definitely would be the  most questionable HTML5
> > detail, it seems to me?
>
> They used to be part of html5, but now are just lumped in the following
> group:
>
> "Features that are not currently in this document that were in the past
> considered part of HTML5, or that were never part of HTML5 but have been
> referred to as part of HTML5 in the media."
>
> > This almost introduces synhcronous two-way sockets in the middle of
> > totaly async www infrastructure... There is no amount of fibre today,
> > which would be enough for all www users to connect to www with a
> > single WebSocket from their browsers. That much is obvious. WebSockets
> > require additional server-side configuration and setup which (for
> > example) Appache (out of the box) does not support today. Neither does
> > IIS, it that matters.
> > 2.
> > On each and every WebSockets spec, I see no other author of the spec
> > but Ian Hickson,  Google Inc. Which strikes me as odd? Is he (and
> > Google Inc) such a capable and unqestionable WebSockets, www leader ?
>
> He is the editor, yes.
>
> > 3.
> > This very simple question is a very big question for WebSockets
> > future : Who and where and why, will provide full WebSockets
> > functionality on the server side ?
> > ( Google will because of CHROME OS ).
>
> Cool.
> > --DBJ

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

slmnhq
In reply to this post by Mike Taylor-15
As exciting as Web Sockets are, they need to be coupled with an
asynchronous server (eg: nginx or lighttpd) on the backend and
probably a message queue (eg: RabitMQ, etc) to be really useful for
building distributed web apps.

For simpler apps that just need constant uni-directional updates from
the server, the new DOM element in HTML5, event-source, is likely to
suffice. AFAIK, only Opera 9 has support for this DOM element so far.

Web Sockets are probably going to become an integral part of web
development, however it's not clear if jQuery will need to offer a WS
interface. It's even possible that 'AJAX' will become obsolete and
jQuery will one day drop support for it and return closer to its goal
of being a pure DOM manipulation library. The networking abstractions
will probably be provided by another javascript library such as js.io
or Orbited.

My two bits.

Salman
http://bitshaq.com

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.

Daniel Friesen-2
In reply to this post by tato-4
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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


12