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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
