gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

Luca's first point is probably the most important. Working offline with
tasks from any online source will only work with some sort of caching.
We could pretend to ourselves that "caching" and a "local backend" are
different things, but that would mostly be a lie :)

  I have user cases to work on this week, and I will mostly focus on
other applications on the desktop, but with your permission Luca I will
include these as well on a wiki page.

  Some thoughts: Any "transforms" of task data should be REVERSIBLE and
BACKEND-AGNOSTIC. By REVERSIBLE I mean that:
        Task A (Backend X) -> Task A (Local File) -> Task A (Backend X)
...should result in an identical object in Backend X.

  Obviously this only applies where Backend X has a *less* sophisticated
task model than GTG—but there are lots of such cases (RTM, iCalendar...
did everyone see my spreadsheet?
http://spreadsheets.google.com/ccc?key=0AhRkDXhnjLt8dHM3MmZ0YmJnMm1UM1hySFNlaDBVc1E&hl=en_GB)

  By BACKEND-AGNOSTIC, I mean that if you have Backend X and Backend Y
that both support the same subset of the GTG data model, then:
        Task A (Local File) -> Task A (Backend X)
        Task A (Local File) -> Task A (Backend Y)
...should produce the same result, *unless* there is some very good
reason to do otherwise.

  Or suppose you also have Backend Z, which contains a set of
information that is a superset of what X & Y hold, but still not the
full GTG model. Then:
        Task A (Local File) -> Task A (Backend Z) -> Task A (Backend X)
        Task A (Local File) -> Task A (Backend Z) -> Task A (Backend Y)
...should ALSO produce the same result.

  I.e. as the task information degrades or is lost, it degrades in a
similar manner for similar backends. This helps ensure that it is
possible to determine Task A (Backend X) == Task A (Backend Y) == Task A
(Backend Z).

On Tue, 2010-06-01 at 14:44 +0200, Lionel Dricot wrote:
> 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
> 
> _______________________________________________
> 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
> 

-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part