- From: Bjartur Thorlacius <svartman95@gmail.com>
- Date: Mon, 06 Feb 2012 23:47:30 -0000
On Mon, 06 Feb 2012 20:08:05 -0000, Matthew Wilcox <elvendil at gmail.com> 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
Received on Monday, 6 February 2012 15:47:30 UTC