4 ms·

The existence of the HTTP Accept header shows that HTTP was designed with a variety of incompatible user-agents in mind. If you write new user-agent, use Accept

The existence of the HTTP Accept header shows that HTTP was designed with a variety of incompatible user-agents in mind. If you write new user-agent, use Accept to specify what content types you can render. Intelligent web servers can serve the same content in different formats for the same URLs. Your browser that only handles HTML will browse on unimpeded, my browser that also handles NewLanguage3000 will get the newfangled version. Everybody wins.

carussell 15y ago
> Everybody wins. You hand out this ribbon far too easily. Parallel offerings[1] are pretty much guaranteed not to be parallel (or resemble it even enough to fool those who want to be fooled). 1. Separate-but-equal, or whatever you want to call it
- rufibarbatus 15y ago
  I'm not sure I get your point, so I may be arguing against something else entirely here. That said, the point of parallel offerings is not to provide identical representations of a given resource. Even XML+XSLT versus XHTML might have different semantical implications, so the best assumption is that no two ways of representing a given content can ever be identical. Well, that's a Good Thing. If I'm requesting a given resource and I signal preference for a PDF-encoded response, that implies on some level that I want a print-formatted, print media version of that resource, whereas its HTML counterpart can be hypertext and multimedia. What you as a server are committing to is that both servings are representations of the same given resource, but without prejudice of putting each format to its best use. This is also beautiful in that if the HTML stack proves to be a bad idea in the long run, rather than being deprecated, it can fall into disuse slowly alongside the slow rise of its successor(s). In fact, there's absolutely zilch stopping us from having more than one canonical format — any server-side MVC (or MVCish) architecture can probably handle that off the box! EDIT: to be sure, the question of how expensive it is to develop for two different representation formats is a whole other story.
  - carussell 15y ago
    > I'm not sure I get your point If it helps, it doesn't look like you did. :) > without prejudice of putting each format to its best use Doing what you can to the extent of what's possible with multiple mediums (yeah, mediums, I said it) is real pie-in-the-sky, false promise kind of stuff. People can't manage today to put the web to anything you could mistake for its best use. Why should it inspire confidence when anyone says it's going to happen when their resources are halved?

carussell 15y ago

> Everybody wins. You hand out this ribbon far too easily. Parallel offerings[1] are pretty much guaranteed not to be parallel (or resemble it even enough to fool those who want to be fooled). 1. Separate-but-equal, or whatever you want to call it

rufibarbatus 15y ago
I'm not sure I get your point, so I may be arguing against something else entirely here. That said, the point of parallel offerings is not to provide identical representations of a given resource. Even XML+XSLT versus XHTML might have different semantical implications, so the best assumption is that no two ways of representing a given content can ever be identical. Well, that's a Good Thing. If I'm requesting a given resource and I signal preference for a PDF-encoded response, that implies on some level that I want a print-formatted, print media version of that resource, whereas its HTML counterpart can be hypertext and multimedia. What you as a server are committing to is that both servings are representations of the same given resource, but without prejudice of putting each format to its best use. This is also beautiful in that if the HTML stack proves to be a bad idea in the long run, rather than being deprecated, it can fall into disuse slowly alongside the slow rise of its successor(s). In fact, there's absolutely zilch stopping us from having more than one canonical format — any server-side MVC (or MVCish) architecture can probably handle that off the box! EDIT: to be sure, the question of how expensive it is to develop for two different representation formats is a whole other story.
- carussell 15y ago
  > I'm not sure I get your point If it helps, it doesn't look like you did. :) > without prejudice of putting each format to its best use Doing what you can to the extent of what's possible with multiple mediums (yeah, mediums, I said it) is real pie-in-the-sky, false promise kind of stuff. People can't manage today to put the web to anything you could mistake for its best use. Why should it inspire confidence when anyone says it's going to happen when their resources are halved?