GTG Services rework blueprint

The services (currently called backends in GTG) rework blueprint is continuation of the many efforts put into making services a pleasant experience for the developers and users. The blueprint takes care of 2 stake holders of GTG: The developers: we need to create a platform which makes it easy for developers to add new services. The users: Synchronization should be smooth with all the features required by the user.

Users: This section deals with changes/enhancements needed to create a smooth user experience while using services and meeting the requirements of the users. General division of services: The services are divided into following categories based on use cases: 1. Local service: Totally featured service. Almost immediate back up of tasks (localfile, evolution) 2. Synchronization service: Tasks synchronized to online service every X minutes (or on request)

• both ways (read/write) - could be degradaded to read only/write only

3. Import service: This service simply imports tasks. A kind of one way sync 4. Read only service: Creates immutable tasks (Whether tags should be editable needs to be discussed) A synchronization engine to take care of the different types of syncs. Provide the basic features needed for these services like, authentication. Handling features that are not available to online service: start date, due date, subtasks; also additional parameters of online service like: estimated time to finish, progress and so on. Give an option to blacklist tags for synchronizing- Every service will have its own tree. Service synchronization can be done in batch or immediately as per user’s wish or developer’s choice. Using GNOME's online config tool. Automatic discovery of services (Gtasks, Pubsub): There could be a notification in GTG asking if the user wants to connect these services with GTG.

Developers: This section deals with changes/enhancements needed in GTG to help the developers while adding a new service Make it easy to develop services. The code for backend should be made minimal (something like just API related) Create a test suite for services- Will require heavy efforts. Once implemented, it will be a great asset for the developers. Make a synchronization engine- This will take care of common tasks like creating a changelist, applying the filter and then making the required changes.

• IMPORT: only checks if there is a task

  - we need a method for that (RemoteId -> task_id) - that RemoteId is unique assume Problem use case: I remove a task from a taglist. Task exists but backend wouldn't see it. proposed solution: just remove RemoteId

General: This section deals with changes/enhancements to make GTG an easy platform to use for developers. Change every name ‘backend’ to synchronization service Split backend to GTG/core/services and GTG/services – The services created by developers will be placed in GTG/services (Similar to plugins) Get rid of BiDict & TwoKeyDict Leverage remote-ids Cleanup code for local XML file. Make from localfile a special backend, cache, not able to make a new instance. (Not reloading from disk?) – This will be specifically useful when we are giving so many options to different services. This will help overcome the errors caused by coding of services.

Suggestion to remove UUID, there is no real usage for it. We should stick to the concept of remote_ids.