gtg-user team mailing list archive

[Duncan Lock <dunc@xxxxxxxxxxxx>]

Sounds very good to me - I would be happy to see gtg acquire this kind of
functionality!

Thanks for all the hard work - love gtg!
Dunc

2009/12/16 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
>
>
>
> _______________________________________________
> 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
>