> I couldn't disagree more with this. It seems unnessacery to have a > server set up where every css/js/xml file has a name change to the > file when it is edited.
I never said anything about files that you (the developer) are editing. We were talking about files that you allow your end-users to edit, using an application you built for this purpose -- and it is absolutely best practice to ensure that those changes are "committed" not only for the user doing the editing, but for all other users who may have viewed the file in its previous form. This is the way hosted image editing must work, or it's not worth offering the functionality. > Images are just another asset to a webpage like js/css/xml. Changing > the name of a css file becuase it has been edited is not a "do it > right" method... Actually, although I never said anythng about non-image files, it is a very good method for optimizing cacheability. We are not talking about changing the file name on disk, we are talking about changing the URI and/or eTag, conservatively and with a precise purpose. These *are* "do it right" methods! They may exceed your interest in pursuing them, or may (erroneously) smack of premature optimization, but they are extremely effective. > and I can't see any reason why images should be viewed differently. I'll give you two reasons. First is size, even with images that the user her/himself can't edit. Your images (800x600+?) are taking up the lion's share of your bandwidth, and your users' as well. You're doing both sides a disservice if you refuse to properly manage cacheability of these objects. Ignoring cacheability of your markup/code/style files may be justified, but not ignoring images. Second is that you are allowing the user to edit images, thus presenting your site as being specifically image-aware, but then refusing to build a proper back end that audits changes in image content and builds URIs accordingly. IMO, even forcing the user to refresh the page manually (if that happened to work around this bug) is poor design. If you offer an online function whose offline equivalent always works in real-time, and you have the ability to have your changes reflected automatically as well, make it so. (Granted, if you are trying to have people *avoid* overusing your primitive mechanism, then not reflecting changes in real-time is good way to make them stop!) You said yourself that you didn't want to break the client-side cacheability of these images. That's good: it means you must have some interest in caching. Then you should ready to take the next big step, when you realize that you can't rely on the most basic/default logic on your server side and the default behavior of common browsers to ensure cachability. You must actively code for cacheability if you care about it at all. --Sandy
