gtg-user team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

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