On Mon, 06 Feb 2012 20:08:05 -0000, Matthew Wilcox <[email protected]>
wrote:
On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
We're discussing HTTP here, so the content might just as well be raster
bitmaps.
Are we? Why, what makes HTTP the relevant factor? SPDY is the future and
already supported in two major browsers., As it compresses headers and
multiplexes, I don't see the issue.
Sorry, my bad. We're discussing an application layer client/server
protocol that can be used for transferring files that don't use CSS pixels.
Multiple and variable screen dimensions are quite common (in special
for projection). That means a request for every screen the resource may
be. For legacy HTTP servers that don't support the new and complicated
If-Different-For-Device header that would have to be added would serve
the same content once for every screen.
No, it means we as a standards body define which gets sent. The sensible
thing is to send the maximum screen size in use on the device.
This is usually, but not necessarily known on page load. I think static
viewport resolution and screen size is the 80% case we should optimize
for, but others (who presumably print documents more often) disagree.
Again, read the proposition I mentioned and you'll find non of this is
true. Extra headers would only be sent by the browser if the browser
received a request for the client to send those headers.
Presumably, this would be decided upon authority-wide (in the URI sense)?
Trying to allow the application layer client/server file transfer protocol
stateless may be overly purist and impractical, but I think highly
descriptive <object>s are a better solution.
--
-,Bjartur
