It would be useful to have something like:
That will remove the addressbook synced if available (as RemovePeer do)
but keep the peer definition retrievable via GetAllPeers.
I would prefer a slightly more general API, one which will also work once (if) we cache more than just contacts. Proposal:
void RemovePeerData(string uid, list of strings)
Removes cached data of the given peer. In contrast to
RemovePeer(), the configuration of the peer and is left
unchanged. As in RemovePeer(), its address book is
automatically deactivated in the unified address book if was
active before removing it.
An empty list removes all data. "contacts" removes only the
Okay? That call would try to completely remove the EDS database file. It might fail if the database is in use (not sure whether EDS then fails to remove or the other users fail).
I was also considering a PurgePeer() call instead, which would have only removed the contacts inside the database. The advantage would be that it is less intrusive if there are other users of the DB (sync, windowed search). The disadvantage is that it is less thorough.
Which one do you prefer?
Hmm, I ran a test and noticed that e_source_remove(), the method used to remove an EDS database, does not remove the local database file immediately. Instead it relies on a garbage collector to remove the obsolete local data.
I'll check with the upstream developers to see how an immediate removal can be accomplished.
(In reply to comment #2)
> Hmm, I ran a test and noticed that e_source_remove(), the method used to
> remove an EDS database, does not remove the local database file immediately.
> Instead it relies on a garbage collector to remove the obsolete local data.
> I'll check with the upstream developers to see how an immediate removal can
> be accomplished.
This is intentional: upstream EDS garbage-collects the database files once per day, then moves them into a "trash" folder and removes them permanently after a month.
This is not the behavior that we want when removing via the PIM Manager API (RemvoePeer or RemovePeerData), so I added code to remove the files right away. I also added a new testpim.py test, TestContacts.testRemove.
I have not implemented RemovePeerData() itself - for that I am still waiting for confirmation about the API.
Eugenio, do you still need the new RemovePeerData() API?
At this stage it is no more required.
But It may be requested again in the next release (q3 2014).
Okay, putting this on hold, to be reprioritized and assigned in the future.
Eugenio, should we schedule this new API for inclusion in 2014?
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/131.