Re: Changing the way exporters work



On Sun, 2008-03-23 at 11:02 +0100, Maurice van der Pot wrote:
> Hi guys,
> 
> Bug #416778 got me thinking about the kind of data that we are currently
> storing in .planner files. This bug is about the work and cost of a task in 
> exported HTML that is calculated incorrectly if the working day does not have
> 8 hours.
> 
> The reason that this bug exists is that we require the exporter to calculate
> these things based on the info in the .planner file.
> 
> The kind of data that I would expect to find in the .planner file is the
> minimum amount of information that is required to recalculate the same
> schedule and nothing more.  On the other hand I would not expect an exporter
> to do any complicated calculations on the schedule (and duplicate algorithms
> in libplanner).
> 
> Which leads me to conclude that exporters should not use the .planner file as
> input. It would be better to have an intermediate data format that planner
> provides to the exporters. This intermediate format should contain anything
> that an exporter could ever need to represent a schedule.
> 
> The current .planner file format should then be stripped of any information
> that planner itself doesn't need.
> 
> Advantages:
> - exporters would be simpler
> - the intermediate format can be changed between planner versions without
>   bothering users with incompatibility issues
> - .planner files would be smaller
> 
> Disadvantages:
> - It would be more difficult to create exporters external to planner, because
>   they would not get the information they got before.
> - if scheduling algorithms in planner became so complex that they took a long
>   time to execute, regenerating the entire schedule when a file is loaded
>   might not be an option anymore. We might be forced to re-introduce some
>   generated data into the .planner file.
> 
> What do you think?

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.

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 ?

-- 
Kurt Maute <kurt maute us>



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