gtg-user team mailing list archive

[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

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