GTG SoC week 2 =?UTF-8?Q?=E2=80=94?= Client/Server Separation



Hi everyone,

  My second weekly report is at http://paul.kishimoto.name/298 . A
version (without hyperlinks, again) follows...

=====

Following on my last week's work mapping the Getting Things GNOME! data
model, week 2 of my GSoC experience involved preparing this
somewhat-lengthy analysis of how we store tasks in GTG, and how it
should change. Of course, it doesn't hold a candle to things like the
168-page iCalendar RFC...of which a good ten percent is devoted to the
recurrence specification grammar for VEVENTs and VTODOs.

Needless to say, I recommended we find a more straightforward way of
solving this bug. To make you read the actual analysis, I won't give
away my other conclusions here!

I have also started a page for user stories to guide future development,
and begun moving around large blocks of code to start to tease apart the
user-facing and core portions of GTG.

Some questions for the Planet hive mind:

     1. Which is preferred idiom — import sys; sys.exit(1) or raise
        SystemExit(1)? The latter avoids an import...
     2. Likewise, most modern PyGTK applications include a
        pygtk.require('2.0') wrapped in a try/execept clause. Is this
        suggested/required in every file that imports gtk, only the
        lowest level, or only once per application (presumably in the
        root or top-level UI module)?

=====

Cheers,
-- 
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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]