Re: Changing the way exporters work

Kurt Maute wrote:
> I'm actually in favor of adding a few fields to the .planner file so the
> external exporters (and other misc tools) don't have to worry about
> making complex calculations.

I'd have to disagree.  Adding duplicate, redundant, and/or inter-related 
information to a data store increases the possibility for bugs to result 
in silent data corruption.  A better approach (IMO) is to put the least 
amount of necessary information in the data store, and centralize the 
data I/O and data manipulation in planner itself.  Provide a versioned 
plugin interface for exporters to plugin to, and a set of functions that 
plugins can use to manipulate the objects.  That way, the data store 
remains simple, there is a single implementation for I/O and data 
manipulation, and you add the ability to dynamically add functionality 
such as exporters to planner.

If you're worried about providing functionality to misc. tools, then a 
shared library with a proper API that both planner and these tools can 
use could be implemented.

> My question is - if we include extra info in the .planner file, who says
> planner has to pay attention to all of it ?  If we ignore some of the
> data on open (stuff that gets recalculated anyway), then wouldn't we
> reduce the number of incompatibility issues ?

Incompatibility between what?

-Seb