gtg-contributors team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

On Sat, May 22, 2010 at 12:25 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> 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.
Ok, but maybe a guy with a lot of bugs like Bryce would like to organize
them, tag them or make subtasks in order to lay out what to do to solve
them.
>
>> 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.
This requires a fair amount of coding. I'm really not sure that this is
very easier than having a simple "if you are newer than me I copy you,
otherwise you copy me".
>
>> 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 ?
It shouldn't be a problem. Every, say, ten minutes, the backends checks
the tasks for changes. We have to do that anyway, because a user will
expect to leave GTG open (or closed) at home, modify tasks on his cell
phone and find them updated at home.

>
> Having the same task in multiple backend allow a lot of broken usecase.
>
> When do you copy or move a task ?
I didn't get this. We can copy tasks? Why shoud it be a problem?
>
>>
>> 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).

I see some more complications. I have a task tagged @Localfile. Now I
clear that tag and use @RTM. I will have to change the uid of the task,
which could cause breakage in parent-child relationship (remember that
our code is asynchronous, you cannot know what's happening).
That simple change causes two id changes (localfile->default,
default->rtm).
ID change is really bad. Consider you have three r/w backends A,B,C. 
you have
  - task @A
    -subtask @B
now you change task @A -> task @B. You have to update subtask @B as
well. If B is online, and you don't have connection, this could cause
problems (or more code).

Consider also that online backends are *dead slow*. On RTM, you're
allowed to make one request per second, and a request is usually
"set_title()" (so, you can estimate the amount of requests necessary).
Even if we are asynchronous, we will be soon a lot behind in our
operations.
This means that:
 -  if the computer freezes/... a lot of  tasks will be lost
 - if the user want to shut down the computer, it will have to wait a
lot or we need to write a cache(which has to consider also that the
remote tasks could change).
 - GTG task loading will be way slower if all tasks are not served at the same
   time
 
>
> 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".
Usercase:
Sandy has her GTG list.
- eat pizza
  - buy pizza
    - something else
Sandy keeps her shopping list on her phone. Therefore, before going to the supermarket, she tags buy pizza @RTM.
Now, RTM does not support subtasks. What happen to "something else"?

>
>
> 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.
Eheh, I see a lot of complications in the other case :)
>
> 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 
> 2) easy to implement
I respectfully contest those two points :)
> Weaknesses :
> 3) There should be some priorities between backends and the UI should reflect this
    3+i)we need to change ids, which is problematic.
    3+2i) task loading/modifying will be slow
    3+3i) we need always an internet connection or we need to write a cache (point 2?)
            The cache must be conserved if GTG is restarted, and updated
            according to the subsequent changed to the relative task.
            Having a cache like that is really like having all tasks in
            the default backend.
> Opportunities : 
>4) Quickly implemented and fixing corner usecases later
 These are not corner use cases. 
 Let's have a simple setup. I want all my tasks on my laptop and on my
 smartphone via..a Tracks backend.
 I am also a FLOSS developer, so I use the launchpad backend.
 That's it.
 Now, I'd like to have my Launchpad bugs in my smartphone. Why can't I?

> Threats : 5) Missing some corner usecases where having multiple backends
> would be useful (Is there some example of such usecase ?)

Two laptops sharing via couchdb and a smarphone via rtm. I want all my tasks on
all of them. It's not a corner case.


>
> 1 task/x backends:
> Strengths : 1) Cover almost every usecase
1+i) speed
2+i) almost no change to GTG core
3+i) works offline
4+i) task backups. I thought about a bazaar backend :)
5+i) tasks in GTG have always the same features. We operate in a "sync as much
as I can basis". This is really good for separating layers, since in GTG core we
don't care where tasks are saved.
> 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.
:D
I hope I've convinced you that 1task/1 backend could not be easier.


>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp
>