Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
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 dbj...@gmail.com
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 jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.comjquery-dev%2bunsubscr...@googlegroups.com
.
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 jquery-...@googlegroups.com.
To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Re: [jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
On 1/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 jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
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 miketa...@gmail.com 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 jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: WebSockets is very faster than xhr. I hope to support of jQuery for WebSockets.
On this sample,
$(Selector).wsload(URL,callback) is like $(Selector).load
(URL,callback)
but, not the same.
Data of load it into a node is not a single message.
Display changes automatically. Change over time and display data being
sent to
On Jan 21, 2:16 am, Daniel Friesen nadir.seen.f...@gmail.com wrote:
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]
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this group,
[jquery-dev] jQuery is Moving to a Forum
Hello All - After much deliberation the jQuery team has decided to close down the Google Groups that we've been using for project discussion and move to a unified forum instead. The new forum can be found here: http://forum.jquery.com/ More information about our decision to move can be found here: http://jquery14.com/day-07/new-jquery-forum If you have any questions concerning the move please feel free to post them in the new meta discussion forum here: http://forum.jquery.com/about-the-jquery-forum Thanks for your continued support and here's to future community discussions! --John -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
[jquery-dev] Re: .SlideUp() + Firefox
I have also observed egregious redraw flicker when using JQuery's animate() function in FireFox whenever content has scrollbars. I've taken a hidescrollbars-animate-showscrollbars workaround. Since most if not all of JQuery's effects are built on top of animate() it seems that any effect that moves pixels and has scrollbars will suffer this same bad fate. On Dec 22 2009, 9:34 am, alexander farkas a.farkas...@googlemail.com wrote: Yes, this is a bigproblem. But, i don´t know a solution. I wrote two workarounds for that. 1. disable scrolbar on body + add padding-right in the size of the scrollbar width (has to dynamically calclated) for the time theanimationoccurs. between disabling scrollbar and callingslideuphas to be a short delay, so that ff can render the disabled scrollbar before animating. pro: - although this sounds very obtrusive, the delayed scrollbar change isn ´t noticed by normal users - this could be easily generalized con: sometimes the bad effect still happens (if someone knows a reason for this, plz tell me) 2. animate the scrolltop of body at the same time to scroll up pro: - if you make the upscrplling a little faster than theslideup, the effect doesn´t appear con: - you can´t generate a generalized code to do this. (multi-colum layout etc) On 22 Dez., 12:39, Peter Wright peter.wri...@renishaw.com wrote: Hello, Has anyone else ever noticed a rather disgusting scrollbar redraw causing a page to flicker when the content shrinks in size (usually triggered bySlideUp())? This occurs when the document's height is reduced gradually causing the viewport's view to be invalid multiple times a second. so the scrollbar has to be redrawn to handle where the viewport's location matches the bottom of the page. If anyone knows of a graceful solution to implement handling a cleanslideUpwhen the viewport is near the document bottom I would much appreciate it, perhaps something to be considered in the 1.4 release? Kind regards, Peter Wright -- This email and any attachments are confidential and are for the use of the addressee only. If you are not the addressee, you must not use or disclose the contents to any other person. Please immediately notify the sender and delete the email. Statements and opinions expressed here may not represent those of the company. Email correspondence is monitored by the company. This information may be subject to Export Control Regulation. You are obliged to comply with such Regulations The parent company of the Renishaw Group is Renishaw plc, registered in England no. 1106260. Registered Office: New Mills, Wotton-under-Edge, Gloucestershire, GL12 8JR, United Kingdom. Tel +44 (0) 1453 524524 -- -- You received this message because you are subscribed to the Google Groups jQuery Development group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
