> So it looks like this: > Timeline_data.xml?12981291823 > > [...] > > A better fix would be one of the following two options: > a) Use the last modified timestamp of file. However this can cause overhead > and performance degradation because of I/O disk seeks to get the filestat.
This, or something close to it (some environments, like an AFS file system, offer file change hooks instead, right in the file system layer rather than at the application layer, as with subversion), is what your web server serving the file *should* do -- if it tries to be clever about sending out cached copies without any ascertaining that the cached copy is still current. Many, many web servers fail this, intentionally (let users kludge the issue, as in your case, and overcaching be the default policy) or by programming/configuration error. > b) The optimal solution (in my opinion) involves some complexity... > Ideally you have a revision control system like subversion to manage > subsequent updates to your xml file and check in and checkout revisions > based on user changes. Using svn hooks you can get the revision number of > the xml file and use that for the append string. Well, it is certainly the minimum net traffic consumption kludge to your problem, if solving it at the web server layer isn't an option. An alternate take, if you know how to invalidate the cache (or, ideally, a specific cache entry for the file in question) in the running web server, is to do that on the commit hook instead. That solution relies on that the server will also send a combination of http headers that will force browsers not to do their own over-caching (the etags header, IIRC, is one that helps a lot in the case of internet explorer, for instance), which is *also* all too common, and not an issue with your ?changing-query hack. You may find it somewhat frustrating trying to get things to work if you do it the right way and by the book, because cache policies and http is a hairy mess that many tiers treat with grave ignorance. It is one of the hallmarks of great sysadmins and server tuners to get working right, IMO. Best wishes and good luck! -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
