Re: Changing the way exporters work
- From: Sebastien Roy <Sebastien Roy Sun COM>
- To: kurt maute us
- Cc: planner-dev-list gnome org
- Subject: Re: Changing the way exporters work
- Date: Mon, 24 Mar 2008 21:50:01 -0400
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?
] [Thread Prev