gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Tue, May 18, 2010 at 05:07:12PM +0200, Lionel Dricot wrote:
> Paul > I like your wiki page but I still fail to see one clear objective.
> I like the idea of having some kind on "tasks generalisation". I immediatly
> do the connection with a DBus representation of a task. Maybe, you should
> talk a bit about that with Bryce.

I don't think there's anything too elaborate about the dbus
representation of a task, it's basically just a dictionary.

Where I think generalization could be of value is to ensure the names of
the members of that dictionary is consistent with as many other
productivity tools as possible, to minimize the amount of conversion
that has to be done when intercommunicating with other tools.

Similarly for terminology for fuzzy date terminology, Tags, Notes, etc.

I don't think this could be formally standardized until it gets suitably
discussed by a range of other projects, but that's definitely outside
the scope of what can be done within a GSoC project.  But a draft
proposal (with researched justifications) to feed that discussion would
be a great output to shoot for in the GSoC project.  And any preliminary
discussions with other projects to bounce ideas around and gather early
feedback would only make those latter standardization discussions that
much easier.

As well, it's possible that this work would identify changes needed to
gtg itself to be more widely consistent.  So that output could be a set
of bug reports (perhaps with patches or branches proposed), that the gtg
team can discuss and consider.

Btw, looking at the Timeline section, I think it is far too ambitious.
(This is a *really* common mistake I make myself far too often.)  You
should probably delete at least 50% of the items so you can invest
deeper focus into the subset you really care about.

> Possible objective : having a "tasks" server, thus including doing the
> separation between gtg-core and the UI. This include making a clear and
> complete DBUS API (that's why I think Bryce advices would be useful). This
> tasks "server" would come with a shitload of tests. To make jml happy, I
> would encourage you to make the tests before the actual code ;-)
> I would also like you to specially consider our cooperation with Hamster
> and Tomboy, maybe by talking with people in there respective communities.

This is a very good idea.  

I think the order the refactoring should be done to minimize breakage
would be: a) analyze what functionality is required by the GUI frontend
and the web frontend; b) implement dbus api calls for this
functionality; c) migrate the GUI frontend to using the dbus api calls
instead of direct calls.

I suspect we might also need to split out the data model stuff into a
third piece as a common shared library.  The codebase is already leaning
sort of in that direction (i.e. /GTG/core), it just needs firmed up and
formalized.

Luca...
> As you have a clear advantage over other students here, I also want you to
> fix some of the regressions from 0.2 to trunk. You can choose which one are
> the most important to fix so your work is useful. 

I think a tangible goal would be to get the codebase into a state where
all of us feel comfortable running 0.3 bzr for our day to day tasks
(currently I stick with 0.2.x due to some of the regressions).

> Karlo > Please read my comment for Paul. As I understand, you will not
> code directly into GTG. Instead, you will code another UI, using Django.
> Consider that the "GTG server" of Paul will be operationnal. I suggest that
> your Django application uses DBus to communicate with the GTG server. You
> will expose the DBus API through a web API so Luca can connect to it and
> you will also do a web interface for those who don't have GTG installed. Am
> I right ?
> 
> I would like you to start by doing a fake task server. A simple python
> script that return fixed constant, completely fake then, but already over
> DBus. This way, you will be able to develop your Django app transparantely
> and connect seamlesly with Paul's work. Take the current gtg-dbus file as a
> model and make it return constant.
> Also, create you Django project :-)

Given a fully fledged dbus api as discussed above, a lot of this project
falls into place.  Indeed, I bet you could take the gtcli script as a
starting point and weave Django service calls into it and you'll have
the core in place.  I made sure gtcli has no dependencies elsewhere into
the gtg codebase, so it's nicely stand alone and probably quite
ameniable to morphing into something more Django oriented.  I bet that
could be done within a week or so, maybe two if you write tests and docs
for everything as you go.

>From that, building a preliminary web view on top of it would make
sense.  That would give you insights into what else needs added to the
API, and would give something visual to show off at the midterm, that
would make everyone happy.  :-)

The synchronization functionality could be very important; if done well
and efficiently, that could form a strong basis for a lot of future work.

Bryce