On 2 Mar 2005 at 5:05, Noel Stoutenburg wrote: > d. collins wrote: > > > Not only [has Coda not] made this promise [of backwards write > > compatibility], but they have always implied the contrary, as > > confirmed by the interviews I read. That's precisely my point. Of > > course, such a feature adds to the complexity of the program, but I > > recall Tobias saying this would even be doable with a plug-in, so it > > can't be that much of problem. > > I don't know how much of a problem it would be, either, and I don't > remember Tobias writing this, but if he did, I know just enough about > programming and software design that it is simpler to write a plug-in > to strip out later features, than to build software to have the > capability to do it or not to do it.
This is simply not true. Look at how word processing software (which I will agree is much simpler than Finale's file format) implements backward (and sideways, to other file formats) write compatibility: by adding file filters. These are little programs that translate from one format to another. The main application only has to be re-engineered to talk to these translation programs. Keep in mind that when you open a Finale file in any version of Finale, you're not actually editing the original file, but a copy in memory. When you open a file from an earlier version, the memory copy is translated from the old to the new format, without a name. Now, a translator layer would only have to take the memory version and write it back in the older file version. This means that certain features would be dropped, since they weren't supported by the old file format. Word and Excel warn you about this, but the losses are much less significant than what you'd have in Finale. So, there'd have to be some thought go into how to inform the user of what is lost, and also of situations where the conversion is probably going to mess things up. My guess is that the vast majority of situations where backward write compatibility would be useful is with near versions, such as 2K4 and 2K2. It's not like there are too many people out there exchanging files with other Finale users who are using Finale 97 or earlier. So, you're not talking about the *huge* changes that go all the way back to the beginning of time, Finale-wise, but just the changes in file format for a few versions back. Now, to do this *really* well, it would probably be a good idea to re- engineer the Finale file format. One solution would be to keep multiple versions of a file in the same file (Excel implemented this in the 97 version), and then the program would need to keep track of changes in the one version that affect structures in the other version. This works well in Excel precisely because its file format is already structured with content and structure stored separately, as well as with redundancy (formulas are stored, but the results of those formulas are also stored). Those kinds of things apply less well to a database format. But what *can* be done with databases is to restructure your data storage structures to make them easier to be backward compatible. One method for doing this is that when you add a feature that requires a file format change, instead of altering the existing data structure, instead add a *new* data structure linked to the old data structure, and have that new structure store the data for the new feature. A messier way to accomplish this would be to have the old file format in one file and the things unstorable in the old format stored in a second file, and then have the translator be smart enough to recombine (with the caveat that you're going to lose things if you do things like, for instance, deleting frames in the old version). This is all complicated, but it's all *separate* from the main application *if* Finale has been properly designed in the first place. > > As for the size of the software, I find this a rather amusing > > argument considering the rest of your post on the size of hard disks > > and on the necessity of keeping several versions of Finale... Or > > were you joking? > > This is partly a matter of comparing apples and oranges. The standard > size of hard drives has increased ten fold in about three years and > about ten fold in the three years before that. In 1999, a 1 GB hard > drive was immense. . . . Malarkey. Dell was supplying 20GB hard drives as standard in 1999. I own just such a machine, bought in Fall of that year. Indeed, even in beginning of 1996, Dell was shipping standard workstations with 2GB hard drives, as I went cheap and downgraded to 1GB (my machine was ordered at the end of 1995, shipped in the first week of 1996). And I had a client who bought a number of Dell workstations between 1997 and 1998 and they all had 4-6GB hard drives -- and those were cheap, low-end workstations. > . . . Furthermore, six years ago, the size of memory > available for operating systems and softare use was probably 100 times > smaller than is commonplace today. On the Windows side, this is not true. In 1999, the standard base RAM configuration for a new PC was 128MBs. Today, it's 512MBs. Now, Macs have seen a much different change, as in 1999, new Macs were still SCSI-based, which was more expensive for large hard drives, and the huge memory requirements of OS X were not yet a reality. So there may be truth to what you say for the Mac, but that's more a function of how behind the times the Mac OS was than it is a comment on hardware. > Second, it is my experience that doubling the size of a software > program squares the complexity of programming (and more importantly, > debugging it), so that I submit that adding backwards write > compatibility would be adding orders of magnitude more difficulty in > debugging and maintaining it. I don't think you really understand modern software architecture. To add backwards write compatibility would require only having a replacement for the code that writes the data files, and if Finale is properly designed, that should be fairly modular and self-contained (it should be implemented that way already, since it would make it easy to implement file format changes with each new version). > Comparing the new, bigger capacity hard drives, with the increase > program size, is a bit like comparing the addition of a new filing > cabinet, with writing a longer essay, in that both adding the larger > hard drive, and the new filing cabinet are trivial compared with > developing a larger computer program, or writing a longer essay. I think the data storage space argument for keeping multiple versions of Finale is certainly spurious, but for completely different reasons. Having all those versions installed makes it more complicated to work with your main version of Finale. I program in Access and have 4 versions installed on my PC (because file formats were not backwardly compatible until recently, when a standard format is kept for all new versions), and it's a real pain to work with. That's *much* more important than the amount of disk space required, which has been trivial for a lot longer than your erroneous description of history would lead one to believe. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
