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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]