gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

On Tue, 2010-06-08 at 01:32 +0200, Luca Invernizzi wrote:
> On Tue, Jun 8, 2010 at 12:59 AM, Paul Natsuo Kishimoto
> <mail@xxxxxxxxxxxxxxxxxxx> wrote:
> > Hi everyone,
> >
> > I just dumped my follow-up analysis of the GTG data model on l.g.o:
> >
> >              http://live.gnome.org/gtg/DataModel/Analysis
> >
> > For those who didn't catch it, this follows on the comparison with other
> > tools & models, which you can also find from:
> >
> >                  http://live.gnome.org/gtg/DataModel
> >
> >  To summarize, I considered ten potential changes to the model that
> > would bring it more in line with other tools. In the end, I came up with
> > three key changes:
> >
> >     1. Add an (optional) priority field.
> >     2. Add an (optional) duration field.
> >     3. Remove the task ID field.
> >
> > #1 and #2 will let GTG be even more helpful to the user in choosing
> > items from the Work View. Because they would be optional, they can be
> > added quickly and implemented in the UI afterwards.
> >
> > #3 is because the task ID and UUID, from all I can tell, do the same
> > thing.
> I've inserted the UUID because the ID was not unique in GTG 0.2.X, and
> that made writing the RTM plugin more complex.
> We can remove the uuid without problems, since it's only used in the
> rtm plugin. In fact, I'm changing task ids to be unique in my
> "backends" work (and the rtm plugin is being retired anyway).
> 
> A small note: each task has its own task id, but also holds the id
> that represents the same task in other backends. It fits your model,
> it's just a generalization of the concept of "id".
> 
> Looking into zeitgeist, I got a completely random idea:
> what if we implement a task URI such as: task://something?
> 
> It could be easy to open a specific task from outside gtg (say, from a
> tomboy note - or zeitgeist)

  That's a cool idea. I know Zeitgeist will require we set up URIs
(similar XML schema URIs; they look like URLs but don't need to resolve
to anything) for distinct task actions -- creating, finishing,
cancelling, etc. But an openable URI per task could also be useful.

  Anyway, I think that is just another reason for keeping the (newer)
UUID and instead removing the old-style ("2@1") ID. The "universally
unique" part, IMHO, makes it a better option.

  Another thing to consider is the synchronization facts/memes, and, as
Bryce mentioned, data pulled in from other backends that is extra/beyond
the GTG model. These are always related to single tasks, but it is
metadata, instead of data.

-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part