gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Le samedi 22 mai 2010 à 11:53 +0200, Luca Invernizzi a écrit :
> 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.


Tasks from RO backends should not be modifiable at all. No way to add a
tag, move it or change the parent. It's read-only. The interface should
reflect that.

> 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.

See above. Read only backend. Thus, you can only read the task.

> 2) allow him to do that, but forget about the changes on restart
> (which may be confusing and annoying)

More than confusing, it would be a bug ;-)

> 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.

What if you modify the task with the RTM backend disabled. And what if
you open it from another computer ?

Having the same task in multiple backend allow a lot of broken usecase.

When do you copy or move a task ? 

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

For me, that's the only real problem related to having one backend per
task.

It could be solved by :
1) defining some "order/priorities" in the backend (difficult part is
having a good UI for that)
2) Having a clear message in the UI when a task change its backend (I
see something like the yellow Gedit "file has been modified" warning).

Also, features not supported by a backend should not be usable with task
in that backend. For example, subtasks could not be used with RTM
backend. That's why, since the beginning I made the backends advertising
its features.

It's make, IMHO, a lot of sense. The subtask features is not enabled,
button is greyed out and a tooltip says : "This task is saved in the
backend %s which doesn't support subtasks".


I foresee *a lot* of complications if we allow multiple backends per
task. I foresee *a lot* of situations where there will be no way to get
the right behaviour.

On the other hand, I don't see so many usecase where only one backend
per task would be a limitation. I mean, currently in Evolution, each
mail is associated to one IMAP account and it's not really a limitation.

So, to summarize what I see :

1 task/1 backend:
Strengths : 1) consistent user experience guaranteed  and 2) easy to
implement
Weaknesses : 3) There should be some priorities between backends and the
UI should reflect this
Opportunities : 4) Quickly implemented and fixing corner usecases later
Threats : 5) Missing some corner usecases where having multiple backends
would be useful (Is there some example of such usecase ?)

1 task/x backends:
Strengths : 1) Cover almost every usecase
Weaknesses : 2) Hard to implement 3) Could lead to very complicated user
experiences 4) Need to discuss a lot of possible usecases and problems
to do the design
Opportunities : ?
Threats : 5) Trying to cover every usecase and just not be good at any
6) Taking too much time and missing the boat, letting the user
enthusiasm sinks


>From my perspective, it is clear that, as long as I'm not convinced by a
specific usecase where 1 task/x backend would be very useful (and I
don't see any, so far), I think we should go the "1 task/1 backend" way.

I know that I changed my mind. It was exchanging mails with all of you
that convinced me.

I admit that, at first, the "1 task/x backends" sounds sexy but, in the
real world, I fear it would be only a geek masturbation and would harm
our targeted users.