gtg-user team mailing list archive

[Duncan Lock <dunc@xxxxxxxxxxxx>]

Yes, I was slightly concerned at the use of titles as keys. It's normally
considered a good idea to use blind keys (a sequential integer, a GUID) for
your record/item ID and then never present this to the user - just show them
the Title. This means that in GTG's case, a task would get a GUID on
creation and then title changes are irrelevant from a backend point of view
- it's just another attribute. As Paul says, if you use a GUID for this,
then it would be unique across all backends & tasks. Is there an obvious
problem with this approach that I haven't considered?

Dunc

2009/12/16 Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>

> These are really interesting concepts, evidently there was a lot of
> thought put into the various possibilities. Three points...
>
>
> 1. The first and second steps seem to be contradictory. The first says
> that the name "Task A" will be globally unique, across all active
> backends. But the second says that "Task A" will need to have an ID
> specific to each backend that stores it—at least one, possibly several.
>
>  Isn't the first step, in essence, turning the task name into a GUID?
> And when using GUIDs, why is there any need for having distinct IDs in
> the different backends? They are globally unique, so there should be no
> collisions.
>
>
> 2. Sync issues will have to be considered for network backends. I've
> been trying to use UbuntuOne (+ couchdb) but have been frustrated how it
> resolves changes, like deleting files. Maybe some sort of graphical diff
> presented to the user asking, "Which version do you want to keep?"
>
>
> 3. The multi-backend concept makes sense but it will be hard to make it
> meaningful & simple for the end-user. This situation reminds me of the
> user interface for Conduit (http://live.gnome.org/Conduit/Screenshots),
> which is pretty, though not perfect, and tries to address the same
> "multi-source, multi-sink, multi-way" config problem.
>
>  Maybe what is needed is a table, with a ROW for every TAG, and a
> COLUMN for every BACKEND. There are some default rows ("no tag", "all
> tasks") and default columns ("local file"). In every cell is an icon for
> [in] / [out] / [both] (or [source] / [target] / [both])——for import AND
> read-only / export / read-write backends, respectively. Also a cell
> could be empty.
>
>  The user can click on each icon to change the behaviour. Some cells
> could be locked...e.g. if the Bugzilla backend is configured (elsewhere)
> to import bugs with the tag "bug", then the Bugzilla column would be
> completely locked, contain an [in] icon on the @bug row, and nothing
> else. Or, the "Local File" backend could have [both] on every row, and
> also be locked. Etc.
>
>
>  All in all, I am excited by what's to come!
>
> On Wed, 2009-12-16 at 23:56 +0100, Lionel Dricot wrote:
> > The following describes my vision of backends and storage in GTG. This
> > is what I intended to do for 0.2. If you agree, it will be done for 0.3!
> >
> > >From the very first lines of GTG, we knew that storing your tasks would
> > be different for everybody. That's why we designed our backend
> > architecture and we designed GTG to work with multiple backends at the
> > same time.
> >
> > Did you know ? GTG already supports multiple backends since 0.1 ! If you
> > manually add a second backend in the backends.xml, it will work like
> > expected.
> >
> > That's fine to read task, but how will the user define in which backend
> > he wants to store a specific task ?
> >
> > Use the already existant Luke! Do you see? Indeed, I'm looking at
> > @tags !
> >
> > So, will it work ?
> >
> > I imagine 4 types of backend you can have : read-write, read-only,
> > import, export.
> >
> > * Read-write is the traditionnal backend you already know. It will also
> > be used for the couchdb backend and, in fact, most backends.
> > * Read-only displays a list of tasks that you have to do but you should
> > trigger something external to close them. It might be useful for
> > backends like bugzilla (at least as a first step) or for centralized
> > backend where your boss have to acknowledge that you finished a task.
> > * Import backends will simply take tasks from the backend, just as the
> > user entered them manually. A typical example might me a Twitter
> > backend. It would retrieve all of your tweets with the tag #todo and
> > create a new task with them.
> > * Export backend write the tasks somewhere but still keep them in GTG.
> > For example, it could export your tasks to a simple task viewer on your
> > cellphone without any complicated sync mechanism.
> >
> > As you can see, I think that RW and Import will already cover most
> > usecases.
> >
> > So, let's call a given instance of a backend a "TaskSource"
> >
> > By default, GTG will start with one tasksource using the current text
> > file backend. It will be possible for users to add other tasksources
> > like you add accounts in Empathy.
> >
> > When adding multiple tasksources, the user has to define a default
> > tasksource. By default, every task will go there.
> >
> > For other tasksources, user will define tags related to each
> > tasksource.
> >
> > For example, if I define a tasksource couchdb with my tasks and that I
> > have, at work, a local file tasksource (tasks about my work are
> > confidential and cannot leave the computer), I can simply say that
> > couchdb is my default and that the local file tasksource catch all tasks
> > with the tag "@work" (including subtags).
> >
> > It means that, at work, I will see my personal tasks and my work tasks
> > when, at home, I will only see my personal tasks.
> >
> > Tasksources will also have the "catchall" option so that every task goes
> > into that particular tasksource.
> >
> > But wait, what if a task as multiple tags and go into multiple backend ?
> >
> > I see two solutions :
> > - we give unique ID to each task, regardless of the backend so GTG
> > understand that this is the same task.
> > - we adopt the "one title = one task" mantra, like Tomboy. Our unique ID
> > is the title! If you create a task with an already existing title, a (1)
> > is added "New Task (1)". If quickadd/create children with an existing
> > name, that existing task is reopened. (that might be useful to find
> > informations about the last time you did that task).
> >
> > If there's a conflict, we might put both version or does something
> > similar : it's only text after all. Also, it means that a given task
> > could have multiple ID. That's not a problem, it only has to be done.
> >
> >
> > Each backend will define itself with a set of options (a bit like
> > plugins). In order to not copy/paste too much, we might have some
> > predefined backends that are instantiated by others. For example, we
> > will have a local-text-file backend for which the user can choose the
> > location of his datas. The default backend will only be an instantiation
> > of that backend but with a fixed data path (value=XDG_HOME_DATA).
> >
> > Backends will also declare if they support specific GTG features like
> > start_date, subtasks and others in the future. For example, the RTM
> > backend will not support subtasks. As a consequence, tasks from the RTM
> > backend will not accept subtasks and this feature will be disabled in
> > them. (of course, RTM plugin will be ported as a backend, at least I
> > hope so !)
> >
> >
> > So, let's take one extreme example :
> > My default tasksource will be a couchdb one so I can access my tasks
> > from everywhere.
> > At work, I will have a local-file tasksource with @work tag (and
> > subtags).
> > I will have an import twitter tasksource that will put in my default
> > tasksource all tweets sent to @ploum with the tag #gtg (including mine)
> > (the tag @fromtwitter will be added)
> > I will have a read-only tasksource that display all bugs assigned to me
> > in Launchpad. Those will automatically have the @gtg tags.
> > I will have an export tasksource that send to my phone every tasks witth
> > the tag @shopping, overwritting the old list at each synchronisation
> > (but, as you can see, the tasks stay in the default tasksource).
> >
> > So, what's my plan to do this?
> >
> > Before everything (step 0), I want to change and improve the backends
> > API. For example, the get_all will no longer returns every single task
> > from the dawn of humanity but will instead retrieve opened tasks and
> > tasks that were closed less that X days ago where X is a parameter,
> > common to all backends, that the user can change. This will solve :
> > https://bugs.edge.launchpad.net/gtg/+bug/312700
> > https://bugs.edge.launchpad.net/gtg/+bug/495758
> >
> > As a compensation, the backends will also (maybe later) have a "search"
> > function. When receiving a search, the backend will answer with every
> > single tasks matching the search, even old ones.
> >
> > But now, we can start the implementation.
> >
> > First, we have to make the name of a task unique.
> > Also, the ID of a tasksource should be unique because that ID is written
> > in the description of tasks.
> >
> > Second step is ensure that tasks could support multiple IDs from
> > differents tasksources.
> >
> > Third step : add support to assign a specific backends based on tags.
> > Yes, it means that tasks migth be first added to the default backend
> > then removed from it once a tag is added.
> >
> > Fourth : we should ensure that removing tags puts well the task in the
> > default backend.
> >
> > Fifth : put a GUI above all of that so the user can choose and configure
> > his own tasksources.
> >
> >
> > This is the vision of a multi-backends tasks system I developed for more
> > than one year. This is the last big stuff I want to add to GTG before a
> > 1.0 release. Of course, nothing is written in stone. I'm open to critics
> > and proposition (mostly from coding people as this is a quite technical
> > proposition). Also remember that GTG is a community project and that my
> > vision will only be accepted if I can convince the majority of
> > developers that this is a good idea.
> >
> >
> > Thanks for reading,
> >
> >
> > Lionel
>
> Cheers,
> --
> Paul Kishimoto
> MASc candidate (2010), Flight Systems & Control Group
> University of Toronto Institute for Aerospace Studies (UTIAS)
>
> http://paul.kishimoto.name — +19053029315
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-user
> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-user
> More help   : https://help.launchpad.net/ListHelp
>
>