 |
 |
Hi all, I have been thinking about the types of values we can use in lifecycle.version. Short text ~~~~~~~~~~ Problem: How to create lifecycle.version values for dynamically generated resources. Solution: Use a hash [1] of the resource. What do you think? Long text ~~~~~~~~~ Working with some content packages on the UKeU LMS, I need to add versioning information to resources such as HTML pages. (AFAIKT, the UKeU LMS only updates resources if the version value has changed.) In a simple world (that I seem to always avoid) with a plain HTML page, I could use a simple revision number (e.g. "1.2" or "261"), or something derived from the date last modified. Importantly, this could be done automatically by the packaging tool, so the value is always updated when the resource is updated. However, my HTML pages are generated from XML, which adds some complications... I might want to ensure that all my HTML files are using the latest XSL by deleting them and re-transforming them from XML. This means that for files that were already up to date no content has changed, but the version is updated. Updating a copy of unchanged resources unneccessarily wastes time and processing capacity on the server. Not a problem for the odd file, but of more concern when dealing with 100's of MBs of course content. Ok, so if I can't use version number derived from the HTML file, how about the source XML file it's generated from? This doesn't work either, as we are concerned with the version of the HTML file - which is affected by the version of the XML source, and the XSL file(s) used to transform it. Maybe combining version numbers of both XML source and XSL could work, but getting the version information from several separate files seems like it could get messy, quickly. Focusing on the HTML page then, we can't rely on a simple version number or date last modified, so how about the content itself? Using a hash function [1] we can get a signature of the file, and using that as the version value will reflect whether the file has changed or not. Downsides to using a hash could include: * Additional processing load on the package creation system * No indication of which version of a resource is younger/older Any thoughts on the pros/cons & cost/benefit of using a hash to generate the version values? (or is there anyone actually using hashes in this way already?) Cheers, Dave. [1] http://www.rsasecurity.com/rsalabs/faq/2-1-6.html -- David Balch. | Web developer. T: +44 (0)1865 286932 | Technology-Assisted Lifelong Learning. F: +44 (0)1865 286922 | University of Oxford. TALL, OUDCE and the University of Oxford accept no legal responsibility for the contents of this message. Any views or opinions presented are only those of the author and not those of TALL, or OUDCE, or the University of Oxford. If this email has come to you in error please delete it and any attachments