gtg-user team mailing list archive

[Izidor Matušov <izidor.matusov@xxxxxxxxx>]

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?

Thanks,

Izidor

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