Chris's Wiki :: blog/programming/AlwaysAllowVersion1 Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/AlwaysAllowVersion1?atomcommentsDWiki2008-12-18T19:33:20ZRecent comments in Chris's Wiki :: blog/programming/AlwaysAllowVersion1.From 209.131.62.113 on /blog/programming/AlwaysAllowVersion1tag:CSpace:blog/programming/AlwaysAllowVersion1:0df136c323fd82c70f19c9bdc07004fc11d8e2fbFrom 209.131.62.113<div class="wikitext"><p>A related idea is that format specifications should always include a built-in offset indicator at the beginning. I'm thinking for example of the mess of mp3 id3 tags. The v1 id3 tags are at the beginning of the file but have to be a small fixed (thus possibly padded) size so as not to confuse music players. The v2 tags go at the end of the file so they can be as large as needed but then you have to seek all the way to the end of the file to find them. I am probably getting a few details wrong but I think essentially this is how it works and I am too lazy to go read wikipedia right now.</p>
<p>Instead the solution to both of these problems is an offset indicator (which points to the start of the file data) at a fixed location close to the beginning of the file. Then any program reading the file can find that locator easily and jump straight to the data section of the file. Also then you don't have to worry about running off the end and hitting metadata when you just want the data.</p>
<p>I realize there are issues here like how many bytes do you reserve for the locator and what happens if it is too small (say its 32 bits and your file goes over 4GB in size), etc. However I think the basic idea makes data files easier to deal with and more flexible.</p>
<p>I think the PNG file specification is a good place to look for ideas on how to do file metatdata correctly.</p>
<p>Phil Hollenback<br>
<a href="http://www.hollenback.net">www.hollenback.net</a></p>
</div>2008-12-18T19:33:20ZBy Chris Siebenmann on /blog/programming/AlwaysAllowVersion1tag:CSpace:blog/programming/AlwaysAllowVersion1:b1532d7dbe3993de6d2ca2077b68bdc612d1af67Chris Siebenmann<div class="wikitext"><p>In the sort of situation that I am talking about, people have already
thought ahead enough to put a version number field into the objects that
they are creating. (For example, I am pretty confidant that ZFS filesystems
have had version numbers since the start.)</p>
<p>When you put an explicit version number into your objects, you should also
put an explicit version number into your API, even if it only accepts one
value in your first release.</p>
</div>2008-12-12T21:52:19ZBy Dan.Astoorian on /blog/programming/AlwaysAllowVersion1tag:CSpace:blog/programming/AlwaysAllowVersion1:cae1c8859b617042e494498c04aeb8762a5f300fDan.Astoorian<div class="wikitext"><p>The first version of a product is very frequently a retronym. Unless a product is exceptionally well-roadmapped, it's often unclear when the first version is released whether or how the next version will even be able to accommodate such backward compatibility, so it may be difficult to guess whether the first version should be called "1," or "1.0," or "0.9", or "--disable-feature-x" (where Feature X is the only non-forward-compatible feature introduced by the subsequent version and it's undesireable to bump the version major just for that change).</p>
<p>A sensible strategy, then, would probably be this: when version 2 is released (supporting the "create with version 1" operation), release a feature enhancement for the older version's tools which implements the same "create with version 1" option as a no-op.</p>
<p>(The end-user may even implement this by installing a wrapper around the original tool.)</p>
<p>--Dan</p>
</div>2008-12-11T17:08:39Z