gtg-user team mailing list archive
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 . 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 , 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 , 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  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
. I've implement CouchDB backend like "Hello World" . It doesn't
deal with the description/parameters of a backend or with authorization.
The interface which should every backend implement consists of these
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
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?