No longer relevant.

Updated description

Regarding activesync_init_subscriptions; I did not address this yet. For the initial usecase this is good enough, and in a future patch I suppose we could read the same setting in synchroton and initalize the subscription accordingly.

The keepalive patch is available sine 0.9.7.

Removed the in-memory cache instead.

New name

In D2143#24421, @machniak wrote:

How about we call self::folders_typedata($prefix); to populate the cache, but then user folder_type() anyways to fetch missing entries (it still uses the cache if available)?

I don't like it for performance reasons, because if we know the folder has no type then why would you bother with a METADATA request? This would create many redundant requests when listing mail folders. And I'm not sure it would solve your issue.

In D2143#24409, @machniak wrote:

With this change METADATA for every folder will be asked separately. This definitely will have performance implications. Maybe a better approach would be to add a method to reset kolab_storage::$typedata (and other cache-like data if needed). And call that method from syncroton's kolab_sync::sleep() or kolab_sync_backend_folder::hasHierarchyChanges().

See https://bifrost.kolabsystems.com/T408794 for context. I verified that the RC UI continues to function (especially activesync and folder config),
so it doesn't brake anything, and that the Ping works better for https://bifrost.kolabsystems.com/T408794

Removed comment that no longer applies

The previous patch was inclomplete as it built on another one, this is the full version.

FWIW, I assume the original code meant to make the case prettier where all folders are below inbox. I think for the affected UI's it shouldn't be a big deal, and avoids the confusing situation we can have right now.

Instead of not showing a tree at all, show it for INBOX as well.

Addressed comments

FWIW, this code was just like this from the beginning, so I don't know if there ever was a valid usecase for it.
Can't think of one though.

Fixed build

For the branch I would propose we base ourselves on the v2.16.0 tag

• no longer fails if some kms is initially unreachable
• allowMoreElements is now taken into account

Added copyright

In D2056#23539, @machniak wrote:

Also, maybe we should tackle this from a different angle. If the folder has been disabled why do we even attempt to sync anything from that folder. We should tell the client that a hierarchy changed. So, maybe the problem is somewhere else, and could be fixed in a better way. We of course can still keep this solution as it prevents from timeout issues caused by other factors.

Addressed comment

Good points.

Tested with up to 200k messages (it failed with 50k before).