On Sat, 2012-09-22 at 12:16 +0200, Ole Wolf wrote: > I've taken a peek at Google's API for tasks synchronization, which is > documented here: > https://developers.google.com/google-apps/tasks/v1/reference/ (at the > bottom of the page). The methods are used via REST which is quite easy > using libcurl if my experience in writing an REST interface for an > Amazon service is any indication.
The protocol itself may be easy; I suspect the tricky part would be to get the data handling and conversion right. As Ildar said (Ildar, you really don't need to worry about the newbie part :-), starting with GData might be better. However, I am not sure whether GData supports tasks. It might not support it (yet). There is an open feature request about Google contacts with some hints regarding the implementation: https://bugs.freedesktop.org/show_bug.cgi?id=52679 As mentioned in the bug report, converting the data from Google into vCard (or iCalendar for tasks) just to emulate existing backends (like the one for Evolution) adds another indirection, which makes it harder to get the data handling right. On the other hand, if GData already has such a converter, it might be the easiest and fastest way to get something working. It's a bit like choosing the high or the low road... > Unless I'm missing something, this would indicate that it would be > relatively straight-forward to write a Google Tasks backend backend > for SyncEvolution, although I suspect the Google authentication > procedure might pose some problems for a non-web interface. > > Has anyone taken a crack at that? No, not beyond considering the idea and some basic research (which probably needs to be redone anyway, because it was a year or more ago). > Otherwise, where do I find documentation on how to write a backend > that fits snugly into the SyncEvolution code? There is an old article which gives an introduction: http://www.estamos.de/blog/2008/08/04/syncml-client-do-it-yourself-style/ The backend API has changed since then, but the general idea is still the same. Use the current backends as example: "file" for a simple, TrackingSyncSource derived backend (change tracking: backend lists all items with a unique local id and a revision string; data exchange: a text format that can be parsed by the Synthesis engine) or "sqlite" (more general backend, does its own change tracking and works with the internal Synthesis representation directly). Ignore that the title says "SyncML client" - the backends work the same no matter for what they are used. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
