> > The budget stuff will be stored in a separate file, probably in
> > scheme forms which will be fairly easy to write out and read back
> > in. Storing the budget in the main file is problematic, as it
> > means the main file format has to change everytime the budget
> > format changes. This is a lot riskier than storing it separately.
>
> Unless it could be encapsulated somehow, but that's going down the track of
> embedded data formats, which I seem to remember were previously debunked on
> this group.
>
> I wrote a versioned portable binary file format which would have coped with
> this problem quite easily to support my PhD work. It would allow one part of
> the file format to be revised without doing any damage to the rest of the dat
> I designed it this way because I was constantly adding features to my program
> and I *had* to maintain backward compatibility so as not to lose access to ol
> data sets. However, I didn't consider robustness against file corruption when
> designed it, which is an important consideration here.
That's very interesting. For now, what we're going to do is use the
file system for something similar. Instead of one data file, there
will be a directory containing the main data file, as well as auxiliary
files like backups, logs, budgets, etc. But there will be an api that
would allow something like you describe to be implemented instead.
dave
