4 ms·

On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can sti

by bmm6o 13y ago

On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.

hcarvalhoalves 13y ago
All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300". It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.
- lukeschlather 13y ago
  Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
  - hcarvalhoalves 13y ago
    > Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
    - lukeschlather 13y ago
      The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed. In an ideal world, it would be server side. But it would easily mean twice as much work to get there.
- canterburry 13y ago
  If I may inject a shameless plug, this is exactly what http://www.pixtulate.com http://www.pixtulate.com does to serve up responsive images and hi/low res images depending on screen resolution. Yes, unfortunately we have to rely on a small client side javascript to detect your client's properties but the solution allows you to both upload and reference one and the same image and URL regardless of client and we'll scale, re-sample and even crop on the fly and cache the formatted image for future requests. We are trying to provide an experience as seamless as HTTP content negotiation.

by bmm6o 13y ago

On the other hand, could that work without server-side code? If the logic is all done in the browser, you don't need support in your web server and you can still load pages straight from disk.

hcarvalhoalves 13y ago

All it would take is some internal rewrite on the server, some directive to serve "lolcat_300dpi.jpg" when the client requests "/media/lolcat.jpg" with an accept header like "image/jpeg;dpi=300". It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.

lukeschlather 13y ago
Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
- hcarvalhoalves 13y ago
  > Theoretically, yes, but that means you need a pretty complicated setup to serve static assets. Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
  - lukeschlather 13y ago
    The way I see it, keeping it in the markup makes it more straightforward to debug. If it's server-side, all of our developers need direct access to the asset server as soon as there are content negotiation issues. If it's client-side, we can share a highly-available asset server and each developer has their code sandboxed. In an ideal world, it would be server side. But it would easily mean twice as much work to get there.
canterburry 13y ago
If I may inject a shameless plug, this is exactly what http://www.pixtulate.com http://www.pixtulate.com does to serve up responsive images and hi/low res images depending on screen resolution. Yes, unfortunately we have to rely on a small client side javascript to detect your client's properties but the solution allows you to both upload and reference one and the same image and URL regardless of client and we'll scale, re-sample and even crop on the fly and cache the formatted image for future requests. We are trying to provide an experience as seamless as HTTP content negotiation.