Slashdot Mirror
HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web
grmoc writes "As part of the 'Let's make the web faster' initiative, we (a few engineers — including me! — at Google, and hopefully people all across the community soon!) are experimenting with alternative protocols to help reduce the latency of Web pages. One of these experiments is SPDY (pronounced 'SPeeDY'), an application-layer protocol (essentially a shim between HTTP and the bits on the wire) for transporting content over the web, designed specifically for minimal latency. In addition to a rough specification for the protocol, we have hacked SPDY into the Google Chrome browser (because it's what we're familiar with) and a simple server testbed. Using these hacked up bits, we compared the performance of many of the top 25 and top 300 websites over both HTTP and SPDY, and have observed those pages load, on average, about twice as fast using SPDY. Thats not bad! We hope to engage the open source community to contribute ideas, feedback, code (we've open sourced the protocol, etc!), and test results."
Now we can see Uncle Goatse twice as fast.
In the future, the content will be loaded before you click! Unfortunately, it's not like it today, so I didn't make the first post...
remove flash, java applets ad's
20X faster!
How is this different from Web servers that serve up gzipped pages?
If only the Google engineers can do something about Slashdot's atrociously slow Javascript. Like maybe they can remove the sleep() statements.
What, just because the original poster pulls a "look at me, I did something cool, therefore I must be cool!" doesn't mean I have to go along with it.
You can generally surf the web ten times or faster if you just
1) Turn off image loading
2) Turn off Javascript
3) Turn off Java
4) Turn off plugins
yeah, yeah... I know... It's called "lynx"
From the link
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
1. Look at top 100 websites.
2. Choose the 25 which give you good numbers and ignore the rest.
3. PROFIT!
Isn't this making what Akamai does free (and likely pissing them off royally)?
today is spelling optional day.
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
I want my old Internet back. And a pony.
Potato chips are a by-yourself food.
The problem isn't pushing the bits across the wire. Major sites that load slowly today (like Slashdot) typically do so because they have advertising code that blocks page display until the ad loads. The ad servers are the bottleneck. Look at the lower left of the Mozilla window and watch the "Waiting for ..." messages.
Even if you're blocking ad images, there's still the delay while successive "document.write" operations take place.
Then there are the sites that load massive amounts of canned CSS and Javascript. (Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)
Then there are the sites that load a skeletal page which then makes multiple requests for XML for the actual content.
Loading the base page just isn't the problem.
Everything plays together nicely for "cloud-gaming" statrups. This will solve, at least to some extent, one of their hardest problems, for free. Except if Google itself is not after exect same market. They never mentioned how Chrome OS is supposed to provide gaiming to users ...
839*929
Will I successfully be able to first-post?
Doesn't that mean that both the client and the server have to be running this new application to see the benefits of this? Essentially either one or the other is still going to be using HTTP if you don't set it up on both, and its only as fast as the slowest piece.
While a great initiative, it could be a while before it actually takes off. To get the rest of the world running on a new protocol will take some time, and there will no doubt be some kinks to work out.
But if anyone could do it, it'd be Google.
Would this make the obligatory "first post" happen even quicker?
This space intentionally left blank.
Am I the only one imagining a ventriloquist controlling a snarky dummy that counters all the points in the summary with dubious half-truths?
Or simply an older man who likes to fondle you?
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
So which ports are you planning to use for it?
Deleted
AOL actually does something similar to this with their TopSpeed technology, and it does work very, very well. It has introduced features like multiplexed persistent connections to the intermediary layer, sending down just object deltas since last visit (for if-modified-since requests), and applying gzip compression to uncompressed objects on the wire. It's one of the best technologies they've introduced. And, in full disclosure, I was proud to be a part of the team that made it all possible. It's too bad all of this is specific to the AOL software, so I'm glad a name like Google is trying to open up these kind of features to the general internet.
Comment removed based on user account deletion
I mean reinventing the wheel, well why not, this one is old and let say we have done all we could with HTTP...
But why, WHY should you call that with a stupid name like SPDY?!? It's not even an acronym (of is it?).
It sound bad, it's years (decade?) before it is well supported... but why not. Wake me when it's done ready for production.
I guess they start to get bored at Google if they are trying not rewrite HTTP.
--- Bouh !!! ---
?
No. Neither can I. It will let them *push* adverts at you in parallel though... *before you asked for them*
Google wanting more efficient advert distribution... No, never...
Deleted
If only the Google engineers can do something about Slashdot's atrociously slow Javascript.
I've noticed a discernible difference in /. loadtime, in favor of Google Chrome vs FF 3.x on Mac OSX at home. And that's just the Chrome dev channel release. I was pleasantly surprised.
Reply to That ||
While we're at it, let's also make processing web pages faster.
We have a semantic language (HTML) and a language that describes how to present that (CSS), right? This is good, let's keep it that way.
But things aren't as good as they could be. On the semantic side, we have many elements in the language that don't really convey any semantic information, and a lot of semantics there isn't an element for. On the presentation side, well, suffice it to say that there are a _lot_ of things that cannot be done, and others that can be done, but only with ugly kludges. Meanwhile, processing and rendering HTML and CSS takes a lot of resources.
Here is my proposal:
- For the semantics, let's introduce an extensible language. Imagine it as a sort of programming language, where the standard library has elements for common things like paragraphs, hyperlinks, headings, etc. and there are additional libraries which add more specialized elements, e.g. there could be a library for web fora (or blogs, if you prefer), a library for screenshot galleries, etc.
- For the presentation, let's introduce something that actually supports the features of the presentation medium. For example, for presentation on desktop operating systems, you would have support for things like buttons and checkboxes, fonts, drawing primitives, and events like keypresses and mouse clicks. Again, this should be a modular system, where you can, for example, have a library to implement the look of your website, which you can then re-use in all your pages.
- Introduce a standard for the distribution of the various modules, to facilitate re-use (no having to download a huge library on every page load).
- It could be beneficial to define both a textual, human readable form and a binary form that can be efficiently parsed by computers. Combined with a mapping between the two, you can have the best of both worlds: efficient processing by machine, and readable by humans.
- There needn't actually be separate languages for semantics, presentation and scripting; it can all be done in a single language, thus simplifying things
I'd be working on this if my job didn't take so much time and energy, but, as it is, I'm just throwing these ideas out here.
Please correct me if I got my facts wrong.
Then the customers will empty their wallets twice as fast!
Do we need a faster http? Really?
And the whole mission statement for this thing takes me back to the days of WAP. In fact all of the optimisation stuff has already been done as part of WSP - but hey, go ahead and re-invent the wheel.
"Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue)"
WTF you do realize that TCP is a head-of-line blocking protocol right? You can layer whatever the hell you want into a TCP channel and its still bound to TCPs shortcommings. If google really wanted to be productive they would leverge SCTP streams rather than reinventing crap that will never be optimal anyway... haha they even list this under "previous approaches" as if its somehow "legacy"
"Exclusively client-initiated requests. "
Nonsense, this was done in netscape 4.x
"Uncompressed request and response headers."
"Redundant headers"
gzip anyone?
"Optional data compression. Content should always be sent in a compressed format"
Its nice that google thinks it can dictate to operators.
If google really wanted to help speed up the fricking web they would discontinue adscense and google analyitics which adds extra RTTs to god knows what percentage of the entire web.
The real problem is all the commercial **CRAP** and too few selfless operators working to help people without expecting back in return.
I've never had to wait to bring up a wikipedia page.
This sound like it would be perfect for cell phone browsers.
I love random hex numbers! Just like this one, 09f911029d74e35bd84156c5635688c0.
Congrats on being the only interesting post so far. Everybody else is just complaining about the bloat in sites nowadays, which is valid, but I guess unavoidable. I just realize some sites might have 200+ inline elements, and the combined HTTP headers (plus TCP, etc overhead) on that isn't trivial, so this technology will surely help. Oh well, that's IT isn't it, Intel builds faster CPUs, and Microsoft builds bloatier software. I installed "Windows Live Mail" and "Windows Live Messenger" for a friend yesterday, and these 2 pieces of software (mail, and chat) takes up 100 MB. 100 MB!
What time is it/will be over there? Check with my iPhone app!
I was thinking about one of the "features" of SPDY
"To enable the server to initiate communications with the client and push data to the client whenever possible"
Would that mean a server can force the images of a html-page upon a client?
If so, the ignoring images will no longer help to speed up the connection.
Also if the pictures (or flash content) are for advertisements,
then it is not so easy anymore to simply block it with today's adblockers.
How about we don't use HTTP/HTML for things they were not designed or ever intended to do? You know, that "right tool for the right job" thing.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Do we need a faster http? Really?
Of course not. HTTP as it exists now is perfect and sublime, and people will still be using this exact implementation over the next thousand years.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
The nice thing about standards is that there are so many to choose from!
Why in the world implement a new standard whose purpose is to speed up the web yet only do it 2x under certain conditions? To be taken seriously, it would have to be orders of magnitude faster, but that's a huge hurdle because the root of the problem isn't the HTTP protocol, but what's happening on the web server (no pipelined connections? slow DB? uncompressed content? sloppy, inefficient coding?) and the end users' bandwidth. The one thing SPDY has going for it is compressing headers and eliminating redundant headers, but that's a small gain really.
In any case, you could simply wait and things will get naturally faster w/o new protocols because servers generally get faster and users' bandwidth increases. And by the same token the benefits of a new in-between protocol would diminish.
SPDY sounds like a really cool open source project if you ask me. Sure, it's not as cool as replacing TCP and HTTP completely but I bet I'm not the only one who's checking out the white paper and the implementation of the algorithms.
It says the goal is
But the testing is on both TCP and SSL/TCP, since:
It's not all rosy as the short documentation page explains. While they are trying to maximize throughput and minimize latency, they are hurting other areas. 2 obvious downsides I see are:
1. Server would now have to keep holding the connection open to the client throughout the client's session, and also keep the associated resources in memory. While this may not be a problem for Google and their seemingly limitless processing powers, a Joe Webmaster will see their web server load average increase significantly. HTTP servers usually give you control over this with the HTTP keep-alive time and max connections/children settings. If the server is now required to keep the connections open it would spell more hardware for many/most websites;
2. Requiring compression seems silly to me. This would increase the processing power required on the web server (see above), and also on the client - think underpowered portable devices. It needs to stay optional - if the client and server both play and prefer compression, then they should do it; if not, then let them be; also keeping in mind that all images, video and other multimedia are already compressed - so adding compression to these items would increase the server/client load _and_ increase payload.
Right. It's not April 1st.
I'm not sure what everybody else is complaining about. Did they read the fine article?
The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.
Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.
you got my new Droid to be able to dial hands-free and sync with Outlook. Would help me out a bunch more than faster http. No, really...
we need some stupid idealistic programmer to do the work we dont want [to do, to spend on, etc]
# To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
The problem for that is now everything is encypted. If it has multiple channels, let one be plaintext of insecure items,a nd one cyphered for encrypted ones
# To enable the server to initiate communications with the client and push data to the client whenever possible.
Horrible idea because now popup and ad blockers don't work. Sure they might not show it, but the server has already sent it to you and eaten up your bandwidth. What are your options? Send a block-list during negotiation? Not likely, and still might not be honored. We need to keep the client in control. What should be done is the server send the component list, and then the client can return the accepted list back to the server to have it put into the download stream. While this is the correct operation, the problem with this is it increases latency.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
This is not supposed to affect applications, just servers or clients, but not sure how the server will "suggest" more files without at the very least parsing the html files served (probably caching a bit, then parsing, then sending the headers with the suggestions and then the actual content).
More than in the application web serves, could be interesting to implement this in the perimetral (caching) reverse proxy servers (like in varnish and others). That won't force changing probably legacy web servers, and implementing it could add some improvement even if this new protocol isnt used by most/all clients.
doesn't it worry anyone that someone who is writing something sitting in layers 4-7 (by the sounds of it|) thinks that TCP is an application layer protocol?
(which is basically proxying from dedicated Opera servers)
"I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
and a few more in the download or as plugins, in the meantime?
> What would be possible if browsing the web was as fast as turning the pages
> of a magazine?
With all ads blocked (including Googles) it already is.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Chrome dev channel release offers bleeding-edge features that are more likely to affect performance positively, at the potential expense of stability. That is not an implication of instability by any means (I use Chromium builds in Windows myself, which are even more bleeding-edge), just a statement of clarification that it's much more of an accomplishment when the final non-beta version achieves good performance.
Have you installed Safari 4.0.4 yet (released yesterday)? Blazing fast for me on a P4M-1.8 occasionally speedstepped down to 1.2 GHz. Well, as blazing as a slow-ass website like /. 2.0 can be. Easily the equal of the latest Chromium builds for me on the same XP system, and yet Safari 4.0.4 is release-quality. And it doesn't do any funky highlighting when dragging the Full/Abbreviated/Hidden comments slider control, unlike what Chromium/Chrome has always done in Windows for me.
I can barely stand bear to read /. 2.0 in any other Windows browser without turning off JS. That includes FF 3.x.
Cache control 4tw. A lot of the user perception problems SPDY is trying to solve can be solved by utilizing already-existing protocol features and the farms of cache servers at ISPs for your active content.
The latency differences between a user going all the way to your server and grabbing your content vs. going to ISP's cache server to get it can be huge when you consider a separate connection for each part of the page. When coupled with the decreased response time (checking a cache file and responding with a 304 is a lot easier on your server than pulling your content out of a database, formatting it and sending the entire page) makes a huge end-user perception difference. It also frees resources on your web server faster because you are sending 20-30 bytes instead of x kb. The faster your server can get rid of that connection the better.
Doing this reduces the load on your server(especially connection utilization), your bandwidth utilization, speeds up the download of your page (since it avoids the need to leave the ISP for your content download) and generally makes you a better network citizen.
Of course this requires developers that understand the protocol.
What I want to know is will ISP cache servers will have this implemented?
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
If they really wanted a faster web, they would have minimized the protocol name. Taking out vowels isn't enough.
The protocol should be renamed to just 's'.
That's 3 less bytes per request.
I can haz goolge internship?
I don't get it. Maybe someone should actually use Google there and lookup "REST" oder "RESTful" and see how the web was designed and SHOULD actually work.
I've already seen the XML based, opaque mess that is Google Wave.
In an ideal world, corporations would not be able to have any say whatsoever in the development of collectively used protocols or languages. The suits are already destroying HTML.
Destroying things for the sake of money, is the only thing that suits know how to do. If you want to actually create something, and create something which is genuinely beneficial and positive in nature, the profit motive has to be removed from the equation.
People also need to stop believing the lies that they are told, that the profit motive is a necessary part of the process. It isn't. We see software development occurring on a daily basis, that the profit motive has absolutely nothing to do with. We also saw communication systems (in terms of the bulletin boards) being developed in the past, which were entirely non-commercial in motive and intent, as well.
Before you develop stars in your eyes about worthless things like Google Wave, try realising that none of the functionality it offers, is genuinely new at all. It is simply an obfuscated hybrid of a number of pre-existing protocols, which work far more effectively on an individual basis.
Instead of the idea advocated here, try using a text-based browser (such as links) for specific tasks, which bypasses all of the advertising, and massively reduces the amount of necessary bandwidth used.
Instead of Google Wave, use IRC.
I'm using the low res version on a 1.3 old duron box with javascript not allowed. It works fine here. If you opt in for the full bloat version, no it doesn't work, but go for the low res version in preferences and it still works OK and is speedy enough and pages scroll OK as well.
At least some of the perception about what is the bottleneck is related to browsers reporting the wrong cause. This should be improved in Firefox 3.6, see https://bugzilla.mozilla.org/show_bug.cgi?id=487638 for more details.
Certainly it's important for Google and others to ensure that our/their servers are responsive, but it's also useful for browsers not to mislead users.
(Full disclosure: Google is my employer.)
Most of the features of fasterfox are found in about:config. There is no sense in installing an addon that will slow the browser down when the browser already has pipelining and prefetching (albeit disabled)
I love it how the know-it-alls jump and say "no, CSS/ads/JavaScript/AJAX/ is guilty". Timothy's post claims an observed twofold increase in speed in practice. Unless you want to flat-out say that he is lying, your arguments are invalid.
But doesn't this sound like another protocol?
So why not just make HTTP into SPDY?
Actually, why not give me a way to prevent the offensive ad loads, especially the hidden/cloaked ads? All these do is slow down my page load and cheat the advertisers. Wait, this is a 50/50 win for me... Well, maybe, but it still makes me wait for nothing I even suspect I want.
A pox on all of them, I say.
deleting the extra space after periods so i can stay relevant, yeah.
So there is still (e.g.) Ethernet, IP and TCP below it? Sounds like yet another layer of inner-platform anti-pattern...
Or is TFS misleading? Application layer is clearly above TCP. But it looks like they created a replacement for TCP/IP from the rest of TFS. (Wich is a bit hard to get the world to use, to make it actually useful.)
Which is it?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
So you can take your proxy and go home.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
Is this the part where Google takes over the interwebs?
This article points to a bunch of other efforts from the past. This list is most notably missing BEEP which also included the ability to multiplex multiple streams on top of TCP at the application layer.
I hope they're able to synthesize all of the thinking from these protocols into their work, and they bring this into the IETF and W3C for discussion when it's appropriate...
HTTP speed really isn't the issue. It's JavaScript performance and the worst culprit are ad servers. Try turning off JavaScript on any major site and it's 10x faster.
"Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs? I want my old Internet back." - by rho (6063) on Thursday November 12, @03:09PM (#30078024) Homepage
I'm using that EXACT speed of connection... & IT FLIES!
How?
Easy...
Use a custom HOSTS file, & then use some GLOBAL disabling of javascript on "every website under the sun" (& ONLY USE IT WHERE YOU ABSOLUTELY HAVE TO).
Both practices result in a FASTER AND S A F E R internet, period (according to my pal Jack, a certified PI, it is "twice as fast"... but, he values the security end more (because he would literally get NAILED, each week, by (&, I kid you not) @ LEAST 200++ viruses/spwyares/trojans/malwares-in-general)).
(So - My word, & my buddy's results not good enough? Fair enough then, ok... how about the word of a published security analyst then from SECURITYFOCUS.COM?)
----
RESURRECTING THE KILLFILE:
(by Mr. Oliver Day)
http://www.securityfocus.com/columnists/491
PERTINENT EXCERPTS/QUOTES:
"The host file on my day-to-day laptop is now over 16,000 lines long. Accessing the Internet particularly browsing the Web is actually faster now."
"From what I have seen in my research, major efforts to share lists of unwanted hosts began gaining serious momentum earlier this decade. The most popular appear to have started as a means to block advertising and as a way to avoid being tracked by sites that use cookies to gather data on the user across Web properties. More recently, projects like Spybot Search and Destroy offer lists of known malicious servers to add a layer of defense against trojans and other forms of malware."
----
"Nuff said/I rest my case..."
APK
P.S.=> You can get good reliable HOSTS files from these sources (stay away from the ones from France @ Wikipedia though - TOO many "falsies" in that one), like WIKIPEDIA's page on HOSTS files -> http://en.wikipedia.org/wiki/Hosts_file, or, mvps.org's is a good one too!
From all the choices in DECENT HOSTS FILES above? Well - I used them ALL... &, I consolidated them ALL into 1 HUGE HOSTS file here via a program I wrote in Borland Delphi 7 to do it, since this involves string processing, some of the heaviest work a PC does in fact, & DELPHI RULES THAT ROOST, even DOUBLING MSVC++ in that speed cateogory, which is why I chose to write my tool in it (I use it to keep duplicates out of & then to "reformat the interior" of the HOSTS I use, to use the smallest/fastest blocking IP address there is for Windows 2000/XP/Server 2003, in 0 preceeding domainnames/hostnames to block out, &/or 0.0.0.0 for Windows VISTA/Server 2008 + Windows 7 (MS made a change after 12/09/2008 taking out the ability to use 0 (smaller & faster) as a blocking "IP Address" in HOSTS files (when it could before that in VISTA, & oddly, Windows 2000/XP/Server 2003 STILL CAN USE 0 (vs. the larger & slower 0.0.0.0 but worse yet, the default 127.0.0.1 "loopback adapter" address)). I wish MS would change this 1 thing in Windows 7 in fact, because IF the do? I would think it is NEAR PERFECT, in fact.
(Plus, keeping them populated & "up-to-date" is easily done if you use SpyBot "Search & Destroy", because it not only 'fortifies' private webbrowser "block lists" like Opera's URLFILTER.INI/FILTER.INI, or also IE restricted zones too (FF has this also), but, it also populates your HOSTS file with blocking entries vs. KNOWN BAD WEBSITES/BOTNET COMMAND & CONTROL SERVERS/BAD ADBANNERS, "automagically" via its IMMUNIZE feature (yes, these too, have had malscript in them the past few years now here & there also), & there are PLENTY of sites like Dancho Danchev's security blog for ZDNet, SRI, FireEye, & many more that provide latest/up-to-date info. on bad sites, so YOU can edit your hosts with notepad.exe & add in blocks vs. those known bogus sites &/or servers yourself, with ease... apk
The server can push the content to you using SPDY, but the client can close that stream (not the connection, so you still get the data you really want).
In other words, the server will not push a terribly large amount of data before your browser can kill it with a FIN message. (It is 1-RTTs worth if the server is doing things according to spec).
Plus, since the priority of server pushed data is low (lowest) any request will immediately pre-empty any pushing that the server is doing.
Also note that just because the server pushes info, doesn't mean that the browser has to use it. It may simply put it into the cache to be used "in the future".. this is essentially how it works in the hacked-up chrome that we have today.
All of your adblockers, etc. should continue to function. :)
While I'm on an off-topic roll, what on earth was the deal with changing the friend/foe indicator from a colored dot to text? What HCI genius at slashdot came up with this absurd change-for-change-sake? It makes absolutely no sense whatsoever to make that change - if the point of the indicator is a quick visual hint at your relation to the poster, then a colored dot is way faster, you get it from peripheral vision almost. Forcing the eye to focus on and read indicator text is distracting and pointless. Every few months I figure this behaviour must at least be a setting in prefs and go looking, but I've never found any mention of it.
~~ Vainglorious Coward
Well said.
I just knew it had to be yet another fuckup. Thanks very much - I'll see if I can track it down now.
is no one else worried about servers with extended open connections pushing data to the client without the client asking for it?. Sure its encrypted, but a decent MitM attack leaves the server wide open and the client expecting unwanted data...
Wait! Whats a sig?
I have always supported K-Meleon, run it myself, and recommended and installed it for others. But since it is based on Gecko, its JavaScript performance is nowhere near the level of Safari and Chrome.
K-Meleon is an excellent lightweight browser with all the strengths and weaknesses of Gecko, perfect for Windows PCs that lag when running Firefox's bloated XUL-based interface. Ideal for advanced users that want deep control of their interface, too.
"right tool for the right job"
Fair enough.
What's the right tool to deliver to your users rich applications which are
I don't know of any tool other than HTTP/HTML. I can imagine something with ssh and X forwarding, but windows boxes don't come with X preinstalled (nor ssh). Remote desktop, perhaps? Any other good ideas?
can we please introduce something to brake IE, they've been braking the web for so long!
Hey... first thing first: normalized at IETF a proper IPv6 label for web document. Then, let IAPs deal with that label. BTW diffserv support is important too because it does work also with IPv4... but in which diffserv class with which priority shall we put the "web document traffic"?
Hear! hear!
-dZ.
Carol vs. Ghost
Not the World Wide Web.
Not Hypertext Transport Protocol.
Not Hypertext Markup Language.
You have a hammer (HTTP/HTML) so everything looks like a nail to you.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
RFC 3229 discusses a design for delta encoding in HTTP. I once stumbled upon this when I thought of doing something like this, as well. This idea makes a lot of sense, but it's well known. The main problem I see is that you need both parties to support it. Since gzip compression in HTTP is fairly common, this is not at all impossible. I have not RTFA, so they may well be proposing something different.
They did it, here's a feature we won't want to live without, yet it guarantees them that Ads are delivered: Server Push. Without it, you have round-trips for each page component. With it, forget adblock, even if you don't want to see the Ad, you downloaded it.
Don't care about the download, you still want adblock? Not in Chrome.
Why are you compressing my jpegs, again?
Science & open-source build trust from peer review. Learn systems you can trust.
Click on Chrome in this article http://www.itproportal.com/portal/news/article/2009/11/4/google-rolls-out-chrome-40-beta-and-updates-its-wave-platform/
and you get an ad for IE8. LOL
Like the beaver, it's just Dam one thing after another
I think you may be wrong on that. It seems that the bug they are fixing is a bug in the 3.6 code as I went to the three test scripts that were mentioned in the comments and with Firefox 3.5.5 everything worked as it should. When I went to the bencamm site it was slow as expected and the slow server mentioned in the status area was the bencamm site and not Google analytics. So it looks like Firefox 3.5.5 does the right thing and Firefox 3.6 didn't do the right thing.
[Not WWW/HTTP/HTML]
I agree partially: I think, as I think you do, that these tools are really poorly suited for the things people want to do, and the things people do could work much better if they were made with better tools.
(display postscript over ssh, perhaps? Wasn't that Sun's NeWS? I've heard good things about it... see also my other suggestions.)
You have a hammer (HTTP/HTML) so everything looks like a nail to you.
I disagree with this bit. I think people want the universal accessibility and zero-administration properties of web applications. I've come up with two non-web ways of delivering that, which probably won't be popular, but... none the less, I'm not fixated on applications having to be web applications. Also, I think not every application should be web-based (in fact, I tend to prefer client-side apps over web apps, all else being equal)
Maybe I'm missing something. Which non-nails am I overlooking?