gtg-user team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Mon, Jul 13, 2009 at 11:32 PM, Lionel Dricot<ploum@xxxxxxxxx> wrote:
> Hello everybody,
>
> As you might know, GTG community is going quite well with a lot of nice
> contribution.
>
> Segphault contributed a nice DBus interface and a review on Ars Technica :
> http://arstechnica.com/open-source/news/2009/07/getting-things-done-with-linux-todo-list-programs.ars
>
> We are present on the French wikipedia :
> http://fr.wikipedia.org/wiki/Getting_Things_Gnome
> (but afaik, not on any other. Mom, look, my name is on a wikipedia page !)
>
>
> It's then time to prepare 0.2. Official 0.2 bug list is here
> https://bugs.edge.launchpad.net/gtg/+milestone/0.2 but can be changed at
> any time.
>
> My vision is the following :
>
> Major 0.2 goal :
> - support for multiple backends
>
> 0.2 optionnal goals are :
> - merge Paulo SoC and its plugin system
> - Bertrand's major treeview refactorisation
> - Merging as many community branches as possible. Request merge as often
> as possible.
>

I'll do what I can :)

>
> Regarding multiple backends support, it's a large piece of work that also
> requires a whole lot of UI design. Here's my vision of this feature.
>
>
> 1) there are three types of backend. read/write, import and export.
>
> 2) one read/write backend will be the default backend. It means that any
> new created task will go in that backend.
>

Unless it's got a tag that goes to a different backend, right?

> 3) An import backend is only a feed for your task list. Periodically
> imported task are then added to your r/w backends. Conceptual example :
> reading an rss feed and adding a new task in your list for each new item
> in the feed. There's no synchronisation. Once the task is created, it's
> created, even if the entry is later removed from the rss feed.
>

IIUC, after it's created, you can still delete it from your other
backends (your default read/write backend?) -- is this right?

> 4) consequently, an export backend only copy tasks to something external
> and do not care anymore about them.
>

Can you give an example for this?

> 5) To know in which backend a task should go, we use… tags !
> So it means that you have a default backend : localxml
> And say that you add another r/w backend : onlinexml
>
> you can then choose in the backend preference that onlinexml is linked to
> @not_work and @personnal
>
> When creating a task, the task is added to localxml. When you add the tag
> @personnal, the task is added to onlinexml instead (and removed from
> locaxml I guess).
>
> As you might guess, it means that the same task could be in more than one
> backend. If we have a "one title == one task" rule, it's not a problem.
>
> I really like the idea of linking backend to tag as it means that backend
> now have a material meaning. You will not forget to put a task in one
> backend because you already used a tag on it.
>

I'm not 100% sure I follow.

Just to confirm, you're saying:
  - tags mean something in the context of my life
  - backends are strongly associated with a tag
  - therefore backends mean something in the context of my life

And then something about not forgetting that I don't quite get :)

> I think it worths discussing this as it will probably be the most
> important feature of GTG. But as soon as we have that, the future will be
> open to nearly everything !
>

It definitely sounds very cool.

I can think of a couple of things that would help me understand this better

The first is a sentence or two answering the question "Why backends?".
I think I've got a rough idea, but it's often good to have these
things written down.

The second would be a quick sketch of the Python interface for a backend.

> Roads ? Where we are going, we don't need roads !
>

:-D

Apologies if these questions have been answered elsewhere.

jml