<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I haven't seen a counterargument to the assertion that it is **incorrect** to control repo membership without allowing plugin validation.</div><span><div></div></span></div></div></div></blockquote><div><br></div></span><div>We could add hooks for plugins to provide validation for each content type. The Content model in pulpcore could define "add_to_repository_version" and "remove_from_repository_<wbr>version" methods that take repository version as a parameter. The default behavior would be that exists now. The Content models in the plugins could then override the methods and provide validation needed for removing from and adding to a repository version. The repository version REST api would then use these methods on the content models to add and remove content. <br></div></div></div></div></blockquote><div><br></div><div>In Pulp 2, core controls the endpoints and uses hooks to involve the plugins but it is difficult to put the right hooks wherever any plugin needs them. That may be an overly simplistic comparison though because I think your proposal is just for add/remove, and not for more complex concepts like sync. The general idea is plausible, but I would want to hear more about how the implementation would look before I try to make technical comparisons.</div><div><br></div><div>Generally, I prefer to avoid the hook pattern in favor of plugin-defined endpoints. The pattern I prefer is "offer plugin writers tools, but stay out of their way."</div></div></div></div>