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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~gtg-contributors > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
