← Back to team overview

gtg-user team mailing list archive

Fedora package maintainer & Spring hackathon (backends)


Hello fellow GTG users and GTG contributors,

(TL;DR - We look for a packager and a communication manager. There will be a spring hackathon in April/May [3]. You can see a new, proposed interface for backends)

I have several announcements to make. Firstly, we are looking for a new Fedora package maintainer for GTG. According to [1], there is nobody who will package GTG for Fedora. Do you want to install GTG as a standard package on Fedora? Just say hello to us or Fedora community!

We are still looking for a communication manager. You would update GTG's blog about the new features, take screenshots, communicate with developers and users. If you want to contribute to GTG but you don't know or don't want to program, it's ideal for you! Respond to this e-mail if you are interested.

The next thing I would like to announce is Spring hackathon! After successful Fall hackathon [2], I would like to ask you to take a part on the next one. The goal will be to write many new backends and have fun by contributing to GTG. You are welcome if you can code or you want to cheer others up. Please, invite your friends who would like to contribute to GTG.

The procedure is the same as the last time. Fill doodle [3] with your name and launchpad nick and the list of days you are available. The hackathon should be on a weekend day in April or May -- it is enough time for you to don't have any other plans for the date of hackathon. Doodle will be open until next Monday, 2012-03-12 and afterwards announced the date of hackathon. Hackathon will take place on our IRC channel (#gtg at GimpNET)

Until the hackathon, I will work on backends infrastructure to facilitate writing your own backend. I've already started working on that: you can find a prototype in lp:~gtg-contributors/gtg/backends20 [4]. I've implement CouchDB backend like "Hello World" [5]. It doesn't deal with the description/parameters of a backend or with authorization. The interface which should every backend implement consists of these methods:

get_tasks() -> returns a list of IDs of tasks on server

fetch_task() -> fetch a single task with given ID. It must return a dictionary with features for GTG tasks

add_task() -> create a new task on server by a dictionary and return ID of a new task

delete_task() -> delete a task on server by given ID

update_task() -> modify a task on server by given ID and the new content of a task

transform_gtg_task() -> transform GTG task object into a dictionary which is used for figuring out what tasks need to be synchronized and for creating an input for add_task() and update_task() methods

I used a dictionary representation of a task instead of task object because many backends doesn't support all GTG features and some of them support features which GTG doesn't support. An author of a backend can specify what features the service supports and which not.

Another nice feature of the proposed interface is that we can build a standalone command line script which will enable you to easily debug your backend.

With those methods is CouchDB backend on about 50 lines which I find it reasonable for people who wants to create a new backend quickly. Do you think that interface could be designed in a better way?



1: https://bugzilla.redhat.com/show_bug.cgi?id=794537
2: http://www.paulocabido.com/gtg/hacking-getting-things-gnome-again/
3: http://www.doodle.com/ypqtv5xmbyknizxv
4: https://code.launchpad.net/~gtg-contributors/gtg/backends20
5: http://bazaar.launchpad.net/~gtg-contributors/gtg/backends20/view/head:/GTG/backends/backend_couchdb.py