Previously we would get sporadic errors from tests when clients do not finalize synchronously in response to g_object_unref(). However this syncrhonous finalization is not really mandated by the API, so instead we give them a grace period to finalize and error out if they fail to finalize eventually.
Missing #include <locale.h>
Not used by Evolution and not clear what this mode even means. Removing it makes a bunch of confusing complexity drop out, which is justication enough for me.
Was tied to "mobile mode", no longer used.
Not used by Evolution and not clear what this mode even means. Removing it makes a bunch of confusing complexity drop out, which is justification enough for me.
The method is not used by Evolution and was partially broken anyway. The boolean return value was overloaded to mean both whether an error occurred AND whether there were more messages to fetch. That's more than two possible states and would have required an additional "out" parameter to clarify, but I'm not going to bother with it.
Rationale: When I originally added Camel's asynchronous API, I thought providers could choose to override the synchronous or asynchronous class methods. Years later, turns out the asynchronous methods were never overridden, and it wouldn't have worked anyway. The asynchronous methods by default invoke an associated synchronous function from a worker thread, but many of Camel's synchronous functions do extra processing around invoking the synchronous class method. camel_store_get_folder_sync() is an example. If a provider tried to implement synchronous methods in terms of the asynchronous methods, then that extra processing in the synchronous functions could potentially get skipped. Removing the asynchronous class methods should help clarify how Camel providers are intended to be written. The removal should have no impact on existing Camel providers, all of which implement only the synchronous class methods. I've even padded the CamelFolderClass struct to keep the binary interface intact.