gtg-contributors team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

I've read the discussion that happened a while ago on backends, so I'll
sum up a few points in favor of the 1 task/x backends intermixed with user cases.
Sorry for the long mail :)
Last note: this needs to be decided soon, because the two approaches are
different and I can't keep writing the low level until this is sorted out
(don't worry, I have still the ui). In fact, a lot of Lionel's remarks on my
 merge request are caused by this.

Pros:

    - working offline is possible. This doesn't need a user case, the advantage
      is quite clear (netbooks...).
      What happens to a modified task if the relative backend has gone offline?

    - as a direct consequence of that, the startup time of GTG is improved (even
      when a connection is present).
      With startup time, I mean from when I launch GTG to when all my tasks are
      listed. Keep in mind that:
         -- some backends can be dead slow, and not very reliable
         -- loading of tasks is async
      So, during loading the user may wonder where has his tasks gone,
      or add them again thinking they got lost.
      With 1 task/x backends, the first backends that load is the default one,
      then all the others sync to it.

    - Creates a very strong separation between backends and GTG core (trees,
      filters & co). No change in core will be needed (apart those already done
      in my merge request that, aside from a few bug fixes, only change the
      Task.sync() function and a little more).
      The critical part for 1 task/x backend is the datastore, which handles
      conflicts (which resolves really in: is this task newer?). The datastore
      is not very big and I've made a very through testcase, so the bug should
      be detected early and confined in few lines of code.

    - Good integration between tasks coming from different backends, since each
      task has all GTG standard features (e.g.:subtasks).
      I'll explain this one with an example:
      I am a student, and I receive in class a practical homework "make bench".
      Being in class, I add that to my RTM account on my cellphone.
      I come home, and my GTG is dutifully displaying my new task tagged
      @ONMYPHONE. 
      To make a bench, I need nails and wood. Therefore, I add two subtasks,
      "buy wood" and "buy nails". I tag the @ONMYPHONE, since I want them back
      there.
      This lets me keep my tasks list tidy inside GTG, while having a
      different "view" of my tasks on my PHONE (because RTM does not
      support subtasks). The view on my phone is messier that the one in
      GTG (being subtasks-organized), so I prefer looking at my tasks on
      GTG, when I can.

      Another example:
      Suppose that I'm already using a web service that does not have task
      descriptions (just titles) or subtasks.
      I discover GTG from a friend, and I decide to give it a try.
      If I'm not allowed to use tasks description or subtasks (as in
      1task/1baceknd)My "GTG experience" would be not great. The browser would be
      just a list of tasks. 
      Now, imagine opening the task editor.
      How can I let this user edit the title without letting him add a
      description? I should consider everything he inputs as a title. Will
      he be able to understand why his GTG is suckier that the one his friend is
      using?

      This problem can also be seen from a backend-writer standpoint. 
      Let's take my case with the RTM plugin. I've first started just syncing
      tasks titles one way. Then, I've added due dates and two way sync. After a
      couple of months I've fixed tags, and after six months task descriptions 
      (which came later than 0.2.4).
      Now, my plugin was included in GTG when it was only syncing task titles
      and due dates and users started using it and blogging about it. For me,
      it was something great, that motivated me to expand it further.
      If we adopt 1task/1 backend, no-one would ever use a not fully developed
      backend, and this will make contributions way harder.

    - Backends are different. This is really a subcase of the previous point.
      Let's take the RTM web services. It is widely used, and yet is does not 
      have a concept of a start date. If anybody used a RTM backend for some of
      his tasks, this will either:
      - pollute the Workview because all the tasks coming from RTM will always
        be displayed
      - if the user would chose to hide @RTM from the workview, he could miss
        something important that he listed there.

    - the very 1 task/x backends is a pros too.
      Usercase 1:
      bryce has a home-work computer and a netbook. He has his main GTG in his work
      computer, but he is bored when he commutes to the grocery store or waits
      while his kids/dog plays, so he uses that time to edit his GTG tasks.
      That's fine, because he can use a couchdb backend between the two.
      Bryce is also fond of his new Windows based phone (it was a gift), and
      being very organized, he'd like to keep his tasks there too: the interface
      is crappy, but is a good fallback when he forgets to bring his netbook
      along. Problem: couchdb on windows mobile is a myth (i think, at least),
      but RTM, Toodledo... work fine.
      
      Usercase 2:
      Bryce has lost his netbook (he doesn't worry, since it was encrypted).
      He is stranded with his phone now. He doesn't use RTM, since it doesn't
      support subtasks, but Toodledo suits him fine.
      He has recently developed a Launchpad backend (I wonder what happened to
      me then, but I digress), and he'd like to sort/edit his bugs on his phone
      too. After all, most of his tasks are derived from bugs. How can he do it
      with 1task/1backend?

    - it makes it easy to make backups of tasks

    - it makes it easy to try new services. Say I'm using the localfile backend
      and I discover that a new CouchDb backend is coming along. I'd like to
      test it, so I add it and link it with the "all-tags-tag" special tag (Why
      is called all-tags and not all-tasks, anyway?). My tasks start syncing
      there, and I can keep them where I know they're safe (in my versioned
      localfile backend). If I don't like the new backend, all it takes is to
      remove it.

    - seamless moving of tasks between backends. Suppose that I am a foolish
      user. I have my task "write thesis outline". I start writing my outline in
      the task description. Then I decide, "ehy, If I can transfer that to my
      blackberry so I can read it later!" (suppose I have a tower
      pc). I add the tag @BLACKBERRY which is linked to a RTM backend and
      puff!
      My task description is gone! The 1task/xbackends avoids that.
      Yes, I can write alerts to show the user each time he does something like
      that, but that means that a lot of alerts will be shown, and that's not
      nice).

Cons:
    - once a backend is activated, other backends get its tasks. If the first
      backend is full of random tasks and is thus removed, the other backends
      will remain polluted. This is easily solved by tagging tasks by their
      origin, though.
    - this list is yours to fill.


There are probably other things, but I believe I've written enough for now, and
I wouldn't want to read a longer email (if I was you) anyway.

I think that the strongest objection against 1task/xbackends is complexity. Let
me just say this: it is complex, but its complexity is kept in just a few
classes which I can write from scratch. The 1task/1backend may have a easier
low-level integration, but a lot of time has to be spent inside GTG core and UI
to disable things according to the backend.

Maybe we should ask the opinion of gtg-user(s)?