gtg-gsoc team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

On Sat, May 22, 2010 at 9:38 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> Le samedi 22 mai 2010 à 01:39 +0200, Luca Invernizzi a écrit :
>> .
>> >
>> > Aren't tasks identified as N@M, where M is the backend number?
>> Yes, but since now we have multiple backends, we just use uuids for tasks.
>> That's because a task can be stored in multiple backends, so a solution like
>> id@backend@pid would be a very good one.
>
> Luca > From my long explanations a while ago, it appeared that having
> tasks stored in multiple backends would be a huge problem (conflict
> handling) and not specially intuitive nor useful.
>
> It was decided to have task only in one backend (if I remember, the
> discussion was mainly with JML).
>
> My suggestion for now :
>
> 1) consider that each task is in one backend and only one.
That's fine for me, because it makes my jobs easier :)
However, from my experience in the RTM plugin, I don't think that
conflict handling would be a huge problem: you just have to compare
modification times.
We have also to consider that a fair set of r/w backends will not
support a series of features that GTG taks have.  Take subtasks, for
example.
Say that I'm an unexperienced user, with my own tasks set, and I
configure a Launchpad backend. I espect to be able to move the new
imported tasks (Launchpad should be a read only backend) and place
them under my task/project "become a great FLOSS guy" and maybe tag
them @FLOSS.
Now, that's not supported by the backend. We can follow two ways here:
1) don't allow the user to do that. We have to explain him why he
can't do that, though, so a fair amount of code has to be written in
core.
2) allow him to do that, but forget about the changes on restart
(which may be confusing and annoying)

If we have the "multiple backends per taks", we can do like the RTM
plugin does: we don't touch attributes that we don't know. So, for
example, subtasks are possible in GTG, but this information is not
forwarded to RTM. Still, a user can exploit all functionalities of GTG
while using the software.

Another problem is: this tag is tagged @Localfile @RTM. Now what I do?

To sum up, I'm not sure that that way is really easier.
> 2) backend number should be unique (use uuid)
They are already, if I recall correctly.


> 3) stay with the task@backend TID for now.
> 4) For retrocompatibility reason, be aware that "@1" means the first
> localfile
No problem. The code works with my current task set.

>
> That's the easiest way I can see to go forward. We will care about other
> problems later.
>
> Lionel
>
>