I'm currently working on new ECal/EBook APIs, which will follow GIO
async API pattern. I found a candidate to be removed, it is
e_cal_get_changes and e_book_get_changes, as these are quite complicated
for both clients and server (from my point of view), and they are not
much implemented in built-in backends:
- from built-in addressbook backends only file backend implements this
- from built-in calendar backends only file and groupwise backends
implement this.

If there is no objection then I'll not add these into the new API. The
old API will be deprecated, but will still be available.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to