Re: Changing the way exporters work
- From: Kurt Maute <kurt maute us>
- To: Maurice van der Pot <griffon26 kfk4ever com>
- Cc: planner-dev-list gnome org
- Subject: Re: Changing the way exporters work
- Date: Mon, 24 Mar 2008 21:16:09 -0400
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]