Craig Parmerlee writes:
> As I suggested earlier, when using an object based storage approach (which > apparently Finale doesn't) the normal practice would be to store multiple > versions of the objects so that back level releases would be able to see > something they recognize.
So when we arrive at Finale2008, each Finale document stores something like 4 different version of each individual note?
A typical rule is n-2 coverage backwards and n+2 forwards. Within that range, only a small percentage of the objects should be affected.
Since when is storing multiple versions of an object the "normal practice" for storing object streams? Doesn't sound very OO to me. I thought that objects normaly was stored with version IDs/tags/numbers, so the running application can extract as much info as it can process from the object.
Multiple versions is a last resort. More typically objects simply gain more properties throughout their life. It is no big deal -- the older release can usually safely ignore the newer properties. But if there is a radical change to the architecture of an object, then storing multiple versions is a successful strategy.
This type of thing is everywhere in the software world, not just in the storage of "object oriented" objects. The best example is HTML. From the very beginning of Mosaic, the browser was designed to parse and discard tags it couldn't recognize, then carry one with the set of tags it did recognize. As HTML evolved, they included mechanisms for authors to include different sets of HTML with that in mind. E.G. the NOFRAMES section that can allow one HTML file to work whether the browser supported frames or not.
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
