On 31 May 2009 at 23:27, Craig Parmerlee wrote: > The "database" doesn't have to be fast. The objects are stored in > memory during program execution. The penalty would only apply when > opening or saving files.
Yes, of course. Autosave would be intolerably slow (unless it saved to some form of intermediary format, but that leads to a whole host of other potential problems). Backups made when you manually save would be intolerably slow. When Microsoft switched its help file format to HTML help, they didn't use plain HTML for storage, but a compiled form of HTML. The reason for this was that plain-text storage was too slow. A help file *really* needs to open quickly, so they decided to optimize the process by using a binary format. > If there is a decoding penalty during runtime > it would surely be negligible. I think you are badly mistaken here. Delays in opening and saving are very noticeable to the end user, and saving is a frequent operation in Finale (because of the automatic saves and backups, and because so many of us have lost data so often in Finale that we save after any signficant operation). > But the underlying premise of that argument, if I understand what you > are saying, is just wrong. You seem to be saying that a proprietary, > highly structured binary format cannot provide forward compatibility. I didn't say that, no. > That is simply not true. ANY file storage system can provide forward > compatibility at very little cost. It is simply a question priorities > and the competence of the system designers. Starting from scratch, perhaps. But when dealing with a legacy app that's been around through 3 generations of OS's and hardware is not nearly as easy. > I haven't designed forward compatibility into every single project I've > every done, The key word here is that you would have "designed" it into your project from the beginning. That didn't happen with Finale. Whether or not it should have is pretty much a moot point at this juncture. > but you can bet I have done that for any project that > anticipated having multiple releases in the field where file > interoperability would be a concern. Honestly, it isn't that hard. Then why is it that only large software companies seem to do it? That is, it's only the developers with deep pockets that seem to have the capability of doing this. And not even all of those do it. I just helped a client who is an account install a new version of QuickBooks Pro. All the files have to be converted to the new version, and it's quite a slow process. If Intuit, a very large software company with deep pockets, can't afford to devote the resources to developing an extensible file format, I think it's pretty unreasonable to expect a tiny company like MakeMusic to be able to devote resources to such a complex project. It's not like the file format is completely divorced from the application. Unless you've designed your app from the ground up with a data access layer that your app communicates with exclusively for file access, you're going to have connections to the file format littered throughout all sorts of areas of your application. I'm sure there is already a data access subsystem in Finale and the UI is not bound directly to that subsystem. But to add features to the file format, you have to add interfaces to the data access subsystem, and you may have to alter existing interfaces when existing structures are extended. So, it gets very complicated. Do you create a new interface to represent the new structure? Or do you somehow extend the properties of the old interface? It's a complicated problem and there's no simple answer. If you create a new interface, then the app has to know which one to use depending on the file format. That means your app needs to know things about the file format, or that you need a layer in between the app and the data access layer. It's not a trivial set of problems. My bet is that Finale has a data access layer, but that it is specific to each version, with interfaces changed to fit the new file format, and the app built on top of it altered to reflect the new interfaces. That is a very simple way to do the job, and it results in no backward compatibility, because the data access layer is tied to a single file format version. As I said above, altering that structure would require: 1. a rewrite of the data access layer. 2. a possible addition of a version management layer. 3. a rewrite of Finale to decouple it from direct communication with a particular data access layer version. And that doesn't even get into the issue of altering the basic file format to be extensible. If you make that change, then you may make it easier to implement interfaces to it (i.e., an extensible format might obviate the need for a version management layer), but at the cost of redesigning your file format. This is not a triviality by any means. > For > a system designer who knows what he's doing, it adds no more than 1% to > the system cost / time and can be done on ANY file storage platform that > I have ever encountered. If done at design time. For legacy apps, it's quite a complicated endeavor. And it has to be error-free. There is *no* margin for error in reading/writing different file versions. It's hard enough to write a converter that is error-free. Since it's a batch operation, it's easy to build in lots of verification routines, but they take time to run (though I must say old Finale files to import very quickly compared to something like QuickBooks files). There would have to be some level of verification in any system that could read/write to multiple file versions, and that in turn would slow things down. > I get that Finale doesn't think this is important and is never going to > do it. I'm simply pointing out they make that decision at their own > peril because for people like me, it makes me less likely to buy every > upgrade. It makes it less likely for a lot of people. But I think you have on some very rose-colored glasses if you think it's not an enormously complicated process for an app that's existed for over 20 years. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
