I thought synchronization would be easier in online mode if -- instead of loading all the sources from the last session immediately -- you first get a list of folders from the server and (based on folder ID) restore the sources from last time on demand.  That naturally weeds out folders from the previous session which don't exist on the server anymore.

During a network outage, yeah, you would want to immediately restore all cached sources from the previous session.  We don't have API for that yet.

It was meant as a convenience, but if it's a hindrance then I can certainly rework it.  The collection backends are still in a prototype phase.

As I pinged you on IRC, the ews sources lost StaySynchronized, if I change them, after restart of the source-factory; same for ema. It's because the source is written from scratch, it (the ews/ema registry backend) doesn't know that it (the source) was already configured.

Are you using e_collection_backend_new_child() to create the new ESource?  This is meant to restore a previously used ESource based on a "resource-id" string (which for ews/ema is a folder ID).

This also requires the ECollectionBackend subclass to implement the dup_resource_id() method, which just extracts the "resource-id" string from an ESource to be used for comparison.  (see how ews does it)

I'm still not sure if I'm getting at the root problem here.  Maybe set a breakpoint on e_source_offline_set_stay_synchronized() to try and catch what's resetting the property?


[1] http://mbarnes.fedorapeople.org/account-mgmt/docs/libebackend/ECollectionBackend.html#e-collection-backend-new-child

I stole the code from ews for ema, and it's almost the same. I can reproduce this on ews too. I think the problem is that after adding the source with [1], the module always rewrites values to its defaults [2], instead of identifying that "I know about this source already". I still want to write some values there, though, like if the folder name changed (the IDs are permanent).

[1] http://git.gnome.org/browse/evolution-ews/tree/src/collection/e-ews-backend.c#n137
[2] http://git.gnome.org/browse/evolution-ews/tree/src/collection/e-ews-backend.c#n167

I think I see what you mean now.  There's no way to tell whether e_collection_backend_new_child() returned a brand new ESource or an ESource restored from a cached key file.

Hmm... wonder if we should break that into two separate functions.

Maybe add an e_collection_backend_restore_child() which you would try first, and if that returns NULL call e_collection_backend_new_child() to just create a brand new ESource.  Then you know whether you're configuring it for the first time.

I'd prefer to have loaded those cached sources on start, thus I can built on them. For example, it takes about 10-20 seconds till my API server returns list of folders, and if I start from fresh in calendar, then it means that those 20 seconds there is no MAPI group, nor calendar, which will mean just confusion for users.

If you load them on start, and do proper handling of remove (like remove also the .source file from ~/cache/evolution/sources/...) then it'll be much better. Currently, as I mentioned in bug #678464 comment #2, I have my EWS folder full of useless .source files.

OK, adding e_collection_backend_claim_all_resources() helped a bit, though there are same cave-eats:
a) I'm forced to re-set e_server_side_source_set_writable() and
   e_server_side_source_set_remote_deletable() to have UI elements
   for "Delete" the source (I know only the later is needed, but anyway).
b) even if I let it delete the foreign source, then it is not removed from
   disk, thus the next source registry start the source is back live.

I also looked into the collection sources folder and I see multiple of them being duplicated for some reason, maybe I caused it when I called the e_collection_backend_claim_all_resources() before actual sync with server folders?

Checkout current ews master, to get my changes for using e_collection_backend_claim_all_resources().

Any progress on fixing this, particularly in 3.6 where it's quite a troublesome regression? Thanks.

Matthew? This regression has been open in 3.6 for a long time now, and it's a fairly painful one.

Your progress on improving Evolution HEAD is massively appreciated, but this kind of breakage is very bad for users (and I unfortunately consider myself to be not much more than a simple user right now, due to time constraints).

If we could get this fixed, it would be very welcome. Thanks!

I partly addressed this for 3.7.91 in eds/ews/ema by properly checking and listening for network changes, thus when you connect to the VPN, the EWS backend recognizes it and tries to update local sources. When you disconnect your VPN, it'll notice it as well. As I said, it's just a partial fix, because it doesn't cover "being in offline".

I partially addressed this in commits "Claim sources even when in offline" for ema (928d7a0) and ews (ed4a49d) for 3.7.91. These are not applicable to gnome-3-6, unfortunately, because they depend on EBackend::online, which doesn't work correctly there.

I keep this bug opened, because the right change should be to do the claim of known sources by ECollectionBackend, not by its descendants, though it seems like the current design doesn't allow this. Another option would be to deprecate ECollectionBackend and stop using it.

(In reply to Milan Crha from comment #12)
> I keep this bug opened, because the right change should be to do the claim
> of known sources by ECollectionBackend, not by its descendants, though it
> seems like the current design doesn't allow this. Another option would be to
> deprecate ECollectionBackend and stop using it.

Let's live with it.