Re: [emacs-wiki-discuss] Planner data design, was Re: planner: why "move" tasks instead of copy?

[Patricia J. Hawkins]

Let me start by saying that planner rocks, and I've been using it
since the beginning of June; thank you all, especially Sacha, for all
your hard work and thought!

Here are some thoughts I'm throwing out for thought and discussion: As
I've worked with planner myself, and watched others work with it, the
data model -- especially with planner-multi in the mix --has been
giving me some major whim-whams (technical term).

One issue: Links to files are effectively keywords for tasks; in order
to create a new keyword, one has to create a new file.  Files
proliferate over hell & gone -- and files also serve other organizing
purposes -- historic record, project groupings.  Could we divorce
keywords from files?  Or at least allow them to be links to
subheadings in files?

Another issue: A basic rule of thumb in programming is that any one
piece of information or data comes from ONE location; it may be copied
elsewhere, but its ultimate, master value is stored in one place only,
and other copies regenerate themselves from that.

The end result is, in planner, data is duplicated all over the place,
and there's no single master location for any one piece of it; people
can choose to use taskpool, but at the moment, it's not part of the
backbone data design.  A change made to a task or note in one location
may or may not get propagated to copies of the task or note.

At the moment, old day pages don't get updated -- which means that
tasks copied forward from old day pages can morph back to old
versions.  This can be fixed -- and the next similar issue can be
fixed -- and the next one.  Sacha and others, how much time do you put
in fixing or changing propagation problems?


-- 
Patricia J. Hawkins
Hawkins Internet Applications
www.hawkinsia.com