[Cosmo-dev] Cacheing bugs on cosmo js

Matthew Eernisse mde at osafoundation.org
Wed Feb 7 12:05:14 PST 2007


Sorry, I wasn't paying close attention to where in the path you were 
adding the version number. Maybe I'm missing something, but is there 
some reason we can't just version the entire 'js' directory? That's what 
I assumed we were doing.

The only reason for not doing this would be if we wanted to version 
pieces-parts separately, and in that case I think we'd be better off 
going with a per-file query-string approach based on the mod-date of the 
file or such that would let us version individual files. But that might 
be overkill for us right now.

M.

Travis Vachon wrote:
> In our fix for bug 7988 
> (https://bugzilla.osafoundation.org/show_bug.cgi?id=7988) we added 
> versioning information to the javascript library paths to make sure 
> users get new versions of the javascript when they upgrade between 
> versions.
> 
> Unfortunately, we did not add versioning information to the path to 
> _our_ code (that is, anything that lives under /cosmo/js/cosmo on the 
> server, or cosmo/src/main/webapp/js/cosmo in trunk).
> 
> This is potentially a problem. If we decide to leave any of our code out 
> the the "distribution file" sitting at /cosmo/js/lib-{version-number}, 
> the code we leave out will need to be grabbed at runtime from 
> /cosmo/js/cosmo, and will be vulnerable to the same problem that caused 
> 7988 (clients using a cached version of the javascript).
> 
> There are a couple solutions to this problem:
> 
> 1) Make sure we always put all of our code into the "dojo distribution". 
> This will mean that the page that downloads the distribution file will 
> get some code it doesn't necessarily need. This will probably be the 
> case anyway, however, since the build is tailored to the /pim page, but 
> clients will download the distribution on the /login page.
> 
> 2) Move the code somewhere else, and move it into 
> /src/main/webapp/js/lib as part of the build process. This will make 
> development slower and more difficult, but would solve this particular 
> problem.
> 
> Any thoughts?
> 
> Travis
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
> 



More information about the cosmo-dev mailing list