Story #9316
Updated by dalley over 2 years ago
This used to be how things worked, then we changed how mirroring worked. But there are rare cases when metadata mirroring is not possible (see related issue) so we should add back a way to do this.
edit: I have two ideas. They are not mutually exclusive, we could implement the first and then later move in the direction of the second without much trouble.
Idea #1
======
A simple extension of our current API. On the sync URL, we would support one additional parameter, which is only valid if mirror=True (else it will either do nothing, or fail to validate). Because it only adds a small option to the sync API and can be done on a plugin by plugin basis, there is no need for a migration.
mirror=False means additive sync, the same as it does currently
For mirror=True mirror_type=$value, a value of:
1. "original" would signify metadata mirroring
1. "reproduction" would signify content mirror + autopublish
(exact names of the modes are open for discussion)
Idea #2
=======
We deprecate the `mirror` option globally, and add a "sync_policy" option to replace it. This would work similarly to "download_policy" and would be a setting on the remote. Instead of being a boolean, many different options could be available, potentially customizable by the plugins. We would discourage using the `mirror` or `mirror_type` options to override this setting, although we would allow it for backwards compatibility.
For metadata mirroring, content-only-mirroring, and additive sync respectively the options would be one of:
1. clone | mirror | replica | exact | exact_clone | exact_replica | exact_mirror
1. content_mirror | content_clone | inexact_clone | inexact_replica | inexact_mirror | reproduction
1. additive
Because this involves changing the remote - probably the base remote class, this would require a migration and a more substantial time investment across plugins.
.