Google Tasks provides standard OAuth 2.0 authorization with only caveat that user needs to copy the authorization code from browser window to GTG (a desktop client) to receive access token & refresh token, else GTG will be required to setup a web server listening to a port to receive authorization code. Also, users behind the firewall will have to grant the incoming port access to GTG for the latter, so it’s much of a hassle for just account authorization which is a one-time deal.
RTM, on the other hand, has OAuth 1.0 authorization, requiring to sign every request, with authorization support for desktop clients such that redirection to a callback URL isn’t required. Todoist simply provides authorization token by username & either password or Google OAuth 2.0 access token (for Log In with Google Account).
While GTG has no special status for top level tasks, all three services handles the top level tasks as projects/tasklists, as suggested by GTD methodology. Google Tasks provides infinite nesting of tasks using parent ids (just like GTG), Todoist only provides 3 levels of subtasks using indent level, and RTM provides none. To handle these differences, service engine will manage top level tasks of GTG as tasklists to be compatible with online services. Moreover, feature to add notes to a task is paid in Todoist.
I will implement a local service plug-in to store the GTG’s tasks locally and then move to implementing service engine and synchronization.
Last few weeks have really been rocky. According to my proposal, I was set to design an API of GTG for the service plug-ins. I read several articles, watchedawesomelectures onAPI design. As I started to learn more and more about APIs, I came to realize my project doesn’t need one. Instead what would really simplify the life of GTG service plug-ins’ developers (hopefully you) would be to just create wrapper functions for (generally RESTful) API of online service and leave the rest of the implementation details to us.
So, I came up with above rough design and resolved the conflicting ideas in my mind, which were slowing me down, with my mentor Nimit. He has been really helpful in resolving my conflicts and providing me a line of thought on approach.
Now, I have been busy implementing service plug-ins so that I can sense the pattern of several API (esp. RTM & GTask, Todoist) out there, which probably would be following the best industry practices. This would help me to decide the design choices for Service Engine.
Moreover, in news, Todoist silently released v5 (directly from v2) of its API along with its apps’ updates.
I’ll be posting again as soon as substantial amount of work is completed.
The status quo of Getting Things Gnome heavily depends on generic backend & local xml database for different third-party services. The class generic backend is inherited by backends for different services. This makes it quite difficult to add new services independent of generic backend, and maintain the core modules, including generic backend, independent of backend service sub classes.
My project aims to introduce several features that make GTG not only developer friendly but also user-friendly. These include detaching backend services from the generic backend such that new & customized services can be added easily, and also improvements in synchronization that will provide flexibility to users.
So, stay tuned for more updates & nightly builds for beta testing, while I get things gnome.