GTG GSoc, week 3 — Grilled cheese sandwiches!

The third week of my Summer of Code project (separating client and server parts of Getting Things GNOME!) was a busy one.

In some long but well-reasoned discussion on the gtg-contributors mailing list, we reached consensus that the GTG data model will add task duration, and drop an older kind of task ID in favour of UUIDs. The duration field will let users estimate how long it will take them to complete a task or set of tasks. As for UUIDs, the benefit ("universally unique") is in the name!

One other proposal—adding a priority field—is still under debate.

Also, the first part of an aforementioned code reorganization went in. (Of about seven bzr branches I've had merged with lp:gtg, the biggest are 1909, 624 and 225 lines, a trend which might continue…but still no match for this!)

This week and next, my biggest task is deciding which DBus interfaces should be exposed by the server part of GTG, and what each one should look like. It turns out that when your application is a delicious grilled cheese sandwich of usefulness, the decision to pull it apart means you need to deal with a glue-like mass of sticky, melted cheese.

…maybe that food-based metaphor will only work for fellow Canadians. What I mean is that a line needs to be drawn across the codebase demarcating what is "server" and what is "client", and in any moderately-complex application that line ends up crossing many, many function calls. The sheer number of these, a non-issue for a monolithic app, becomes problematic because each will need to be spec'd and later maintained to spec.

In this case, the way out was to grep up a list of calls from the GTG UI to GTG core. Examination of this list suggested several ways to streamline the flow of data, which become work items that give me lots of coding to do. Onward!