As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!
When we're talking about requiring compression, we're talking about compression over the headers only.
In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).
Oh, also.. the measured in-lab 2X speedup was without any server push. Who knows, maybe the HELLO message will eventually include a flag that says that the server shouldn't push anything to the client. We're already talking about how to rate-limit anything speculative like this (so that client-requested content is almost never held up with content that is speculatively pushed).
# 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
We've had ideas along these lines-- specifically, we need to work on caching! One proposal that we had was that we'd send cryptographic hashes on the secure channel, then send the static data in the clear on a non-encrypted channel. Alternatively, the data could be signed, and no communication would be necessary on the secure channel. In any case, there is a lot of work to do on this, and we by no means have the answers right now. We just want to make the experiment public, and get as many people involved as we can so that we all end up with something better.
# 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.
Well, the fact the server sends the data doesn't mean that the browser has to interpret it or render it. In the protocol, if/when the browser notices the server sending something it doesn't want, the browser can send a FIN (letting the other side know it should stop), and then can simply ignore the rest. It uses up some bandwidth, but it is really not that much worse than today... especially if we find that the real world tests also show it to be 2X faster on average!!
BEEP, if I remember properly, was about an extensible protocol, but didn't focus on the issues relevant to speeding up browsing. It could be used, but it would introduce some inefficiencies that we currently don't believe are a good tradeoff.. However, we really want the community's input on this (so long as they're willing to do experimentation and measurement to back up opinions!)...
Right now the plan is to use port 443. We may as well make the web a safer place while we make it faster. The plans for indicating how a client/server speaks SPDY is still somewhat up in the air.... what we have planned right now, is: UPGRADE (ye olde HTTP UPGRADE). and, putting some string into the SSL handshake that allows both sides to advertise which protocols they speak. If both speak SPDY, then it can be used. This is nice because you don't have the additional latency of an additional roundtrip (and that latency can be large!)
Its not the same, really... SPDY could do prefetching (in which case it'd be server push, instead of a new pull), but mainly what it does is it lets a lot of requests use the same connection, and does compression on the HTTP headers. Thats essentially almost all of the current performance advantage (for today).
Allowing people who claim to have a condition, and test negatively to it should not influence public policy, nor perception. Alas, today, they do.
And so.. rational people will continue to react strongly (and negatively) to the (apparently unfounded) claims that people make in an attempt to keep the pendulum from swinging too far into irrational territory.
Yea.. I loved that, especially as I was the one who wrote a bunch of the RaceFX code, originally.
That was a very complex system involving hardware in -many- locations (each car, various points in the stadium, in the TV compound, etc. etc). It required a tractor-trailer's worth of stuff each week (several miles of cable can take some space too:) ).
It was stressful (consider having to recompile your application during a commercial break because the producer/director don't like something)..., but rewarding!
The browser opens up a certain number of connections (call it N) to the site. For sites/pages with a lot of small resources, given the stupidity of HTTP, you can only essentially have N requests in flight at once. For many pages (especially those which load images, such as yahoo/google/MS maps), this is the real page load bottleneck.
Yea yea, some very wise person will mention pipelining. Well, try it. It -can- work some of the time, but proxies out there on the great wild 'net may execute your requests out of order, even if you receive the responses in order. Wouldn't it be fun to have that happen for requests which change some state? You mean you don't want to have the bank pay someone before you've deposited a check (stupid example, but you get the idea)??
Browsers are internally limiting the number of connections they make to a site, as the spec says they should.
The spec here is wrong/stupid. Developers are getting around this limitation by making additional domains. Some downgrade the HTTP protocol version to HTTP/1.0 (versions of IE support twice as many connections for 1.0 keep-alive connections as for 1.1 connections) Unfortunately, that requires another DNS domain, and another DNS lookup.
The browser should really just ask the site if it is OK to make more connections. I keep hoping to have time to interact with the standards people about this (yes it is possible, people, you just talk to them!), but don't have time.
Are you crazy, or just overlooking the obvious (or stupid)? If you're rating an honest-to-god bad cop, would you want them to know your name? There is a reason, for instance, that we vote anonymously.
While it is true thgat a degree is often a prerequisite for getting many jobs, I disagree with your assessment of a university's purpose. What you're describing is a trade/vocational school. These exist. They train people job-skills. What Universities exist for is different-- they exist to teach and to learn. The imparted knowledge is only partly informational-- a good university teaches you patterns or ways of thinking that can be applied to many (and varied) situations.
As someone who hires programmers (and being one myself), I expect a programmer to understand the concepts of programming. I do care about them knowing specific langauges, but this is merely a plus-- any good programmer will pick up a new language without much ado.
Java is troublesome as it doesn't teach concepts that a good programmer should know. These concepts include (but are not limited to) pointers, cachability/fitting into cache, program memory size, tradeoffs between maintainability and code speed, asynchronous IO (e.g. select, poll) and others.
A more succinct summary-- java programmers often seem (unless they have knowledge of other lower-level languages) to have little awareness of what the interaction is between their software and the hardware. This is purely based on my experiential evidence.
Lets say that the machine was running for 100s. 50 seconds of that time, it spent running process A. 50 seconds of that time, it spent running process B.
The 50 seconds of A may be distributed differently by different algorithms. In some algorithms, A will run for 50 seconds, and then B will run for 50 seconds. Obviously, this is not the best when you want some interactivity... In other algorithms, the running of A and B will be interspersed, for instance, A may run for 200ms, followed by B for 200ms, etc. until the 100 seconds is up. This gives a more interactive system.
Note that both of these algorithms give a 'fair' amount of time to each process, but one is only fair when 'fairness' is computed at the end.
A "better" algorithm, e.g. Inigo's CFS, EDF, GRRR (GR3), VTRR, etc. will also attempt to be fair on -small- timescales with divergent (and possibly grossly divergent) weights.
You make a copy the same way you make the original.
Using Blu-Ray-Rs would be more expensive than simply pressing a new master and making new disks, for large quantities. Why bother? The large-scale pirates wold make a new master, and have at.
So, you're saying that nerds don't care if the gov't doesn't listen to them? This seems overreaching. What is your basis in making this determination, other than your gut feeling?
Why the hell do the various moderators believe that this is an insightful comment?
It raises no arguments, and postulates only that nerds may not care about this news/issue. What is insightful about it? Obviously some don't care about it, and many do. This is true of -any- issue brought forth for discussion on this site. This is hardly insightful-- it is obvious.
Yup. Welcome to the internet and the new paradigm.
I have little sympathy-- They want absolute control over the works, for 70 years, despite the obvious fact that this is not what the market wants! The market wants a more dynamic approach to content acquisition. If they'd embraced the technology, instead of fighting it, then they wouldn't have to deal with the consequences of the law which they pushed for.
Instead of content on demand, we have a seeming dearth of good programing, and an increase in the amount of advertisement. One has to wonder if either of these factors have a role to play in the movement of content from the authoratarian control of the network execs to the more facile playground of the 'net.
Keep in mind that a fair bit of what people communicate is expressed in common shared experience, and a chunk of that shared experience is copyrighted content, so of COURSE people are going to want to share that with others if they want to communicate with them!
I keep hearing a lot of sympathizing for the copyright-holders, but am not seeing the real change to their bottom line. What I AM seeing, however, is a lot of fear and uncertainty about the future of the content distribution and control channels that these companies have established. I am also seeing a lot of artificial roadblocks being thrown up in the face of actual innovation. The face of technology has been altered, and convenience sacrificed, and it -appears- to be based on fear instead of fact.
Random interesting points: Viacom had a gross PROFIT of 4.8 billion dollars in 2005. Viacom had a gross PROFIT of 5.4 billion dollars in 2006. Hollywood makes most of its money now from DVD sales, and not necessarily from broadcasting or theater showings. We pay money for cable TV today. It didn't used to have ads on all the channels.
You're conflating possession with ownership. 'Their' may imply either of the two, and sometimes both, but not necessarily both.
In any case, looking at the history of patent legislation here: http://caselaw.lp.findlaw.com/data/constitution/ar ticle01/39.html#2 you can see that, indeed, "Only the writings and discoveries of authors and inventors may be protected, and then only to the end of promoting science and the useful arts."
Kendall v. Winsor, 62 U.S. (21 How.) 322, 328 (1859); A. & P. Co. v. Supermarket Equipment Corp., 340 U.S. 147 (1950).
Indeed, the history for this stuff is quite a bit longer than 200 years.
As to this statement:
"Look, people - ownership rights = capitalism, which is still the most efficient economic system that history has yet devised."
The US economic system (and most any western European economy) is a mix of pure capitalism and socialism. Pure 'capitalism' tends to end in monopoly instead of a competitive market. Markets are only efficient when the consumer has sufficient information to make correct choices between producers, and competition exists amongst multiple producers.
Slashdot Mirror
Heya, what about the protocol doesn't support REST?
I'm not aware of anything, but if you can point it out, I'm happy to try to fix it.
As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!
When we're talking about requiring compression, we're talking about compression over the headers only.
In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).
Oh, also.. the measured in-lab 2X speedup was without any server push. Who knows, maybe the HELLO message will eventually include a flag that says that the server shouldn't push anything to the client. We're already talking about how to rate-limit anything speculative like this (so that client-requested content is almost never held up with content that is speculatively pushed).
# 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
We've had ideas along these lines-- specifically, we need to work on caching! One proposal that we had was that we'd send cryptographic hashes on the secure channel, then send the static data in the clear on a non-encrypted channel.
Alternatively, the data could be signed, and no communication would be necessary on the secure channel.
In any case, there is a lot of work to do on this, and we by no means have the answers right now. We just want to make the experiment public, and get as many people involved as we can so that we all end up with something better.
# 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.
Well, the fact the server sends the data doesn't mean that the browser has to interpret it or render it. In the protocol, if/when the browser notices the server sending something it doesn't want, the browser can send a FIN (letting the other side know it should stop), and then can simply ignore the rest. It uses up some bandwidth, but it is really not that much worse than today... especially if we find that the real world tests also show it to be 2X faster on average!!
BEEP, if I remember properly, was about an extensible protocol, but didn't focus on the issues relevant to speeding up browsing. It could be used, but it would introduce some inefficiencies that we currently don't believe are a good tradeoff..
However, we really want the community's input on this (so long as they're willing to do experimentation and measurement to back up opinions!)...
We had a different name before. Alas, many of the better names are already taken...
Hopefully this shouldn't be proprietary at all.. We're open sourcing it, after all!
That definitely sounds interesting... I'd love to speak to people about that!
Right now the plan is to use port 443. We may as well make the web a safer place while we make it faster. .. what we have planned right now, is:
The plans for indicating how a client/server speaks SPDY is still somewhat up in the air..
UPGRADE (ye olde HTTP UPGRADE).
and, putting some string into the SSL handshake that allows both sides to advertise which protocols they speak. If both speak SPDY, then it can be used.
This is nice because you don't have the additional latency of an additional roundtrip (and that latency can be large!)
Yes, it means that both sides have to speak the protocol.
That is why we want to engage the community to start to look at this work!
Heh, no it doesn't mean you have to go along with it...
But to answer your question, it is quite different from gzipping the pages!
Its not the same, really...
SPDY could do prefetching (in which case it'd be server push, instead of a new pull), but mainly what it does is it lets a lot of requests use the same connection, and does compression on the HTTP headers.
Thats essentially almost all of the current performance advantage (for today).
Allowing people who claim to have a condition, and test negatively to it should not influence public policy, nor perception.
Alas, today, they do.
And so.. rational people will continue to react strongly (and negatively) to the (apparently unfounded) claims that people make in an attempt to keep the pendulum from swinging too far into irrational territory.
Yea.. I loved that, especially as I was the one who wrote a bunch of the RaceFX code, originally.
That was a very complex system involving hardware in -many- locations (each car, various points in the stadium, in the TV compound, etc. etc). It required a tractor-trailer's worth of stuff each week (several miles of cable can take some space too :) ).
It was stressful (consider having to recompile your application during a commercial break because the producer/director don't like something)..., but rewarding!
Bzzzt. Wrong!
The browser opens up a certain number of connections (call it N) to the site. For sites/pages with a lot of small resources, given the stupidity of HTTP, you can only essentially have N requests in flight at once. For many pages (especially those which load images, such as yahoo/google/MS maps), this is the real page load bottleneck.
Yea yea, some very wise person will mention pipelining. Well, try it. It -can- work some of the time, but proxies out there on the great wild 'net may execute your requests out of order, even if you receive the responses in order. Wouldn't it be fun to have that happen for requests which change some state? You mean you don't want to have the bank pay someone before you've deposited a check (stupid example, but you get the idea)??
Browsers are internally limiting the number of connections they make to a site, as the spec says they should.
The spec here is wrong/stupid. Developers are getting around this limitation by making additional domains. Some downgrade the HTTP protocol version to HTTP/1.0 (versions of IE support twice as many connections for 1.0 keep-alive connections as for 1.1 connections)
Unfortunately, that requires another DNS domain, and another DNS lookup.
The browser should really just ask the site if it is OK to make more connections. I keep hoping to have time to interact with the standards people about this (yes it is possible, people, you just talk to them!), but don't have time.
Are you crazy, or just overlooking the obvious (or stupid)?
If you're rating an honest-to-god bad cop, would you want them to know your name?
There is a reason, for instance, that we vote anonymously.
While it is true thgat a degree is often a prerequisite for getting many jobs, I disagree with your assessment of a university's purpose.
What you're describing is a trade/vocational school. These exist. They train people job-skills.
What Universities exist for is different-- they exist to teach and to learn. The imparted knowledge is only partly informational-- a good university teaches you patterns or ways of thinking that can be applied to many (and varied) situations.
As someone who hires programmers (and being one myself), I expect a programmer to understand the concepts of programming. I do care about them knowing specific langauges, but this is merely a plus-- any good programmer will pick up a new language without much ado.
Java is troublesome as it doesn't teach concepts that a good programmer should know. These concepts include (but are not limited to) pointers, cachability/fitting into cache, program memory size, tradeoffs between maintainability and code speed, asynchronous IO (e.g. select, poll) and others.
A more succinct summary-- java programmers often seem (unless they have knowledge of other lower-level languages) to have little awareness of what the interaction is between their software and the hardware.
This is purely based on my experiential evidence.
Let me put it this way.
:) )
Instead of processes, we have people.
You give person A 1,000,000 dollars when they're born.
You give person B 1,000,000 dollars a second before he dies.
Is it fair?
In the end, they'd been given the same amount of money, right?
(The answer is no: it isn't fair
Lets say that the machine was running for 100s.
g )
50 seconds of that time, it spent running process A.
50 seconds of that time, it spent running process B.
The 50 seconds of A may be distributed differently by different algorithms.
In some algorithms, A will run for 50 seconds, and then B will run for 50 seconds.
Obviously, this is not the best when you want some interactivity...
In other algorithms, the running of A and B will be interspersed, for instance, A may run for 200ms, followed by B for 200ms, etc. until the 100 seconds is up.
This gives a more interactive system.
Note that both of these algorithms give a 'fair' amount of time to each process, but one is only fair when 'fairness' is computed at the end.
A "better" algorithm, e.g. Inigo's CFS, EDF, GRRR (GR3), VTRR, etc. will also attempt to be fair on -small- timescales with divergent (and possibly grossly divergent) weights.
Wikipedia has a fairly nice page with links to more information:
http://en.wikipedia.org/wiki/Scheduling_(computin
You make a copy the same way you make the original.
Using Blu-Ray-Rs would be more expensive than simply pressing a new master and making new disks, for large quantities.
Why bother? The large-scale pirates wold make a new master, and have at.
What about this?
http://wendy.seltzer.org/blog/archives/DMCA.html
So, you're saying that nerds don't care if the gov't doesn't listen to them?
This seems overreaching.
What is your basis in making this determination, other than your gut feeling?
Why the hell do the various moderators believe that this is an insightful comment?
It raises no arguments, and postulates only that nerds may not care about this news/issue.
What is insightful about it? Obviously some don't care about it, and many do. This is true of -any- issue brought forth for discussion on this site. This is hardly insightful-- it is obvious.
Yup. Welcome to the internet and the new paradigm.
I have little sympathy-- They want absolute control over the works, for 70 years, despite the obvious fact that this is not what the market wants! The market wants a more dynamic approach to content acquisition. If they'd embraced the technology, instead of fighting it, then they wouldn't have to deal with the consequences of the law which they pushed for.
Instead of content on demand, we have a seeming dearth of good programing, and an increase in the amount of advertisement. One has to wonder if either of these factors have a role to play in the movement of content from the authoratarian control of the network execs to the more facile playground of the 'net.
Keep in mind that a fair bit of what people communicate is expressed in common shared experience, and a chunk of that shared experience is copyrighted content, so of COURSE people are going to want to share that with others if they want to communicate with them!
I keep hearing a lot of sympathizing for the copyright-holders, but am not seeing the real change to their bottom line. What I AM seeing, however, is a lot of fear and uncertainty about the future of the content distribution and control channels that these companies have established. I am also seeing a lot of artificial roadblocks being thrown up in the face of actual innovation. The face of technology has been altered, and convenience sacrificed, and it -appears- to be based on fear instead of fact.
Random interesting points:
Viacom had a gross PROFIT of 4.8 billion dollars in 2005.
Viacom had a gross PROFIT of 5.4 billion dollars in 2006.
Hollywood makes most of its money now from DVD sales, and not necessarily from broadcasting or theater showings.
We pay money for cable TV today. It didn't used to have ads on all the channels.
You're conflating possession with ownership. 'Their' may imply either of the two, and sometimes both, but not necessarily both.
r ticle01/39.html#2
In any case, looking at the history of patent legislation here:
http://caselaw.lp.findlaw.com/data/constitution/a
you can see that, indeed, "Only the writings and discoveries of authors and inventors may be protected, and then only to the end of promoting science and the useful arts."
Kendall v. Winsor, 62 U.S. (21 How.) 322, 328 (1859); A. & P. Co. v. Supermarket Equipment Corp., 340 U.S. 147 (1950).
Indeed, the history for this stuff is quite a bit longer than 200 years.
As to this statement:
"Look, people - ownership rights = capitalism, which is still the most efficient economic system that history has yet devised."
The US economic system (and most any western European economy) is a mix of pure capitalism and socialism. Pure 'capitalism' tends to end in monopoly instead of a competitive market. Markets are only efficient when the consumer has sufficient information to make correct choices between producers, and competition exists amongst multiple producers.