That's your own fault. Don't buy hardware that's tied to a "free" online service. The cost of maintenance is built into continued sales. Once those sales stop, so does the funding. And definitely don't be surprised when the inevitable happens.
The same is also true of any home automation hardware you find in the big box stores. API points to a server run by the manufacturer or it requires an iOS/Android app or both.
Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.
SPDY will allow later requests to be answered before the first one. You seem to be focusing on the aspect of re-using old stale connections. I'm talking about the many dozens of connections needed on the initial visit to a web site right now.
I hope your kidding there are no useful transaction semantics defined for POST requests or any other HTTP verbs. Any assumption this is somehow safe today is wrong. It can only be made safe by application layer detection.
The RFC itself says that it's vulnerable to replay attacks. Even more so than what's currently in use.
There's a different type of HOL blocking specific to multiplexed HTTP pipelining (at the next highest protocol layer). If one resource is slow to load because of being dynamic, it can hold up the entire queue. That's not an issue with SPDY or HTTP/2.0.
My understanding is that your browser cookies and user agent string would be re-sent with every request using RFC7413. That's not small. And it can't handle POST requests safely, meaning fragmented protocols.
The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC. SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.
Head of line blocking is really only an issue for dynamic content. Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests. And nothing is going to be stopping you from using your bandwidth. Sure, if you have some progressive jpegs, but those are almost completely out of use now because it adds to the filesize.
When I said lots of tiny files I was referring to generally static content. But having all of these on one subdomain and the dynamic content on the primary domain name will allow this to happen asynchronously. Pipelining would still fix this as long as we don't let go of all our other current tricks.
If the content is on another domain, it loads simultaneously in a separate HTTP request. It just takes longer to complete that smaller (but slower) request than it takes to load the entire rest of the web site.
And some web sites don't define a fixed width/height for the ad, meaning the page (or big chunks of the page) doesn't actually render until the ad finishes loading.
I think the major ad networks have some serious bottlenecks. Always the last thing to load. You would think that fixing that would be a huge priority considering it leads to people installing Adblock. That's the primary reason I've installed it for people - not because the sites they go to have ads in intrusive locations.
Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.
As a web guy, I still use primarily XHTML. I may call it HTML5 when I need to use an HTML5 tag, but for a true developer/designer who doesn't use a GUI, properly nesting tags is a must. And with HTML5 being so loose, most XHTML documents are also valid HTML5 documents.
Also - being able to load another web site's XML-compliant DOM to scrape data (for personal use)? Priceless.
But your app can't mention any of this directly in the app. Otherwise, they'll expect you to exclusively offer that service as an in-app purchase and give them their 30%.
A lot of that is cost savings from shared infrastructure. There are multiple telecom wires running through my city (cable, phone, fiber) but only one power grid. Yet you can buy your electricity through another supplier.
In fact, electricity is cheap because of new reserves of natural gas that is cheaper than coal. If you believe electricity generation is crumbling, you're believing the propaganda from the coal industry.
I do know that if there isn't a commercial-laden broadcast model, then there is nothing to subsidize me enjoying multiple full seasons of a show all at once. Too big of a risk to produce so much. This either means more junk content is on the way or it means a more direct relationship will be forged between content producers and viewers.
For example, paying 20th Century Fox television for a subscription to Firefly. Or paying Mutant Enemy Productions and their financial backers directly. Kickstarter is the right idea, but this world takes big seed money to produce even a pilot.
At least content providers are willing to offer it and take my money. Too much for me, too. But if you don't watch too many new shows and have Netflix also it could be cheaper than cable TV.
The only way to get a package without ESPN is to also be without Disney Channel and your local ABC affiliate. Which is also fine for a lot of people. But the content provider has chosen to force all or nothing bundling for licensing fees.
But not as it always will be. Why do you think so many are cutting the cord and moving to Netflix? Waiting a couple years to binge watch an entire show is actually more enjoyable than dragging out a show across 5 years anyway.
say I want Doctor Who, Walking Dead, Big Bang Theory, and Phineus and Ferb, and each of those requires a separate subscription of $10-20, then I end up paying more than what I did when I was a satellite subscriber.
I think iTunes already does this for many shows. You can buy a season bundle (works out to over $2/episode) and get access to the episodes as they air.
which means ESPN is forcing Dish to broadcast its old channels in the old tiered system... and not allowing them to show ESPN (For $7/month or whatever) without also including ESPN Classic at the very same price in the same tier
And you forgot that non-sports watchers have to have both channels just to get access to the Disney Channel.
If they'd stop selling exclusive broadcast rights (at least by country), you'd have a chance of that. And since the upcoming events for the foreseeable future have already been sold, you'd have to wait a while even if they did strike a deal.
And so you're right:
http://www.imdb.com/title/tt00...
. Intelligence is knowing when to give up and go back to the drawing board.
Cue obligatory obscure Ernest video:
https://www.youtube.com/watch?...
That's your own fault. Don't buy hardware that's tied to a "free" online service. The cost of maintenance is built into continued sales. Once those sales stop, so does the funding. And definitely don't be surprised when the inevitable happens.
The same is also true of any home automation hardware you find in the big box stores. API points to a server run by the manufacturer or it requires an iOS/Android app or both.
Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.
SPDY will allow later requests to be answered before the first one. You seem to be focusing on the aspect of re-using old stale connections. I'm talking about the many dozens of connections needed on the initial visit to a web site right now.
I hope your kidding there are no useful transaction semantics defined for POST requests or any other HTTP verbs. Any assumption this is somehow safe today is wrong. It can only be made safe by application layer detection.
The RFC itself says that it's vulnerable to replay attacks. Even more so than what's currently in use.
There's a different type of HOL blocking specific to multiplexed HTTP pipelining (at the next highest protocol layer). If one resource is slow to load because of being dynamic, it can hold up the entire queue. That's not an issue with SPDY or HTTP/2.0.
My understanding is that your browser cookies and user agent string would be re-sent with every request using RFC7413. That's not small. And it can't handle POST requests safely, meaning fragmented protocols.
The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC. SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.
Head of line blocking is really only an issue for dynamic content. Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests. And nothing is going to be stopping you from using your bandwidth. Sure, if you have some progressive jpegs, but those are almost completely out of use now because it adds to the filesize.
When I said lots of tiny files I was referring to generally static content. But having all of these on one subdomain and the dynamic content on the primary domain name will allow this to happen asynchronously. Pipelining would still fix this as long as we don't let go of all our other current tricks.
If the content is on another domain, it loads simultaneously in a separate HTTP request. It just takes longer to complete that smaller (but slower) request than it takes to load the entire rest of the web site.
And some web sites don't define a fixed width/height for the ad, meaning the page (or big chunks of the page) doesn't actually render until the ad finishes loading.
With how much of HTML and other standards that Internet Explorer is responsible for, we should be glad that Google is having an influence.
I think the major ad networks have some serious bottlenecks. Always the last thing to load. You would think that fixing that would be a huge priority considering it leads to people installing Adblock. That's the primary reason I've installed it for people - not because the sites they go to have ads in intrusive locations.
Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.
As a web guy, I still use primarily XHTML. I may call it HTML5 when I need to use an HTML5 tag, but for a true developer/designer who doesn't use a GUI, properly nesting tags is a must. And with HTML5 being so loose, most XHTML documents are also valid HTML5 documents.
Also - being able to load another web site's XML-compliant DOM to scrape data (for personal use)? Priceless.
Plenty of SAAS solutions do exactly this.
But your app can't mention any of this directly in the app. Otherwise, they'll expect you to exclusively offer that service as an in-app purchase and give them their 30%.
There are quite a few states that allow this sort of setup:
http://www.alliedpowerservices...
And it's the same as the situation with DSL over POTS already (but there are few providers on the market).
A lot of that is cost savings from shared infrastructure. There are multiple telecom wires running through my city (cable, phone, fiber) but only one power grid. Yet you can buy your electricity through another supplier.
In fact, electricity is cheap because of new reserves of natural gas that is cheaper than coal. If you believe electricity generation is crumbling, you're believing the propaganda from the coal industry.
I don't know...you have to give them points for not saying "your an idiot."
I do know that if there isn't a commercial-laden broadcast model, then there is nothing to subsidize me enjoying multiple full seasons of a show all at once. Too big of a risk to produce so much. This either means more junk content is on the way or it means a more direct relationship will be forged between content producers and viewers.
For example, paying 20th Century Fox television for a subscription to Firefly. Or paying Mutant Enemy Productions and their financial backers directly. Kickstarter is the right idea, but this world takes big seed money to produce even a pilot.
At least content providers are willing to offer it and take my money. Too much for me, too. But if you don't watch too many new shows and have Netflix also it could be cheaper than cable TV.
The only way to get a package without ESPN is to also be without Disney Channel and your local ABC affiliate. Which is also fine for a lot of people. But the content provider has chosen to force all or nothing bundling for licensing fees.
AS IT HAS ALWAYS BEEN.
But not as it always will be. Why do you think so many are cutting the cord and moving to Netflix? Waiting a couple years to binge watch an entire show is actually more enjoyable than dragging out a show across 5 years anyway.
If you're going for off-topic....
slashdot.org 127.0.0.1
www.slashdot.org 127.0.0.1
say I want Doctor Who, Walking Dead, Big Bang Theory, and Phineus and Ferb, and each of those requires a separate subscription of $10-20, then I end up paying more than what I did when I was a satellite subscriber.
I think iTunes already does this for many shows. You can buy a season bundle (works out to over $2/episode) and get access to the episodes as they air.
which means ESPN is forcing Dish to broadcast its old channels in the old tiered system... and not allowing them to show ESPN (For $7/month or whatever) without also including ESPN Classic at the very same price in the same tier
And you forgot that non-sports watchers have to have both channels just to get access to the Disney Channel.
And ESPN's content on the service is probably just full episodes of produced programming, not live coverage of sports.
If they'd stop selling exclusive broadcast rights (at least by country), you'd have a chance of that. And since the upcoming events for the foreseeable future have already been sold, you'd have to wait a while even if they did strike a deal.