On Tue, 2010-06-08 at 01:32 +0200, Luca Invernizzi wrote: > On Tue, Jun 8, 2010 at 12:59 AM, Paul Natsuo Kishimoto > <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
