Re: Changing the way exporters work

[Kurt Maute <kurt maute us>]

On Wed, 2008-03-26 at 20:44 +0100, Maurice van der Pot wrote:
> On Mon, Mar 24, 2008 at 09:50:01PM -0400, Sebastien Roy wrote:
> > 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.
> 
> That reminds me. We already have the libplanner interface for external
> exporters (of which there are none afaik, so it's not a big deal either
> way).
> The html exporter uses the .planner format because it is easy to feed to
> xsltproc. I'd keep this path the same as it is now, only with an
> intermediate file format made specifically for this purpose.

I agree with Sebastien from a developer's perspective.  I'm just
concerned that if we limit the amount of data too much, then the
non-developer public might be a bit put off to have to use libplanner to
get all the data they need... like if someone wanted to write a
stylesheet to transform the data into csv, or do some quick scripting to
analyze the data in some way.

So although we don't have to make a decision right away, I think we
might consider either a secondary (non-default) export format with more
data, or just teach the Planner open function to ignore data it doesn't
understand (which will work unless we take out or change the nature of
existing fields).


-- 
Kurt Maute <kurt maute us>