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 <[email protected]> > 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 : [email protected] > Unsubscribe : https://launchpad.net/~gtg-user > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~gtg-user Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-user More help : https://help.launchpad.net/ListHelp
