Yes, I was slightly concerned at the use of titles as keys. It's normally considered a good idea to use blind keys (a sequential integer, a GUID) for your record/item ID and then never present this to the user - just show them the Title. This means that in GTG's case, a task would get a GUID on creation and then title changes are irrelevant from a backend point of view - it's just another attribute. As Paul says, if you use a GUID for this, then it would be unique across all backends & tasks. Is there an obvious problem with this approach that I haven't considered?
Dunc 2009/12/16 Paul Natsuo Kishimoto <[email protected]> > 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 > > _______________________________________________ > 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
