gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Just for the record : I'm still not 100% convinced by 1/X but if Bryce and
Luca are, chances are that I'm missing something.

So, let's go for 1/X solution. Chances that I will be fully convinced in
during the code writing (I hope so)

Lionel



On Tue, 1 Jun 2010 13:31:45 +0200, Luca Invernizzi
<invernizzi.l@xxxxxxxxx>
wrote:
> 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)?
> 
> 
> 
> 
> _______________________________________________
> 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