<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 11:34 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 11:20 AM Justin Sherrill <<a href="mailto:jsherril@redhat.com" target="_blank">jsherril@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>If a plugin provided multiple remotes, for example, what would
that look like?</p>
<p>in your example:</p>
<pre><code class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete">-</span>file_remote = fileremotes.<span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943eyecatcher">remotes_file_file_</span>create(remote_data)</span>
<span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-1552284183194660336gmail-m_-7135414750268891943insert"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943insert">+</span>file_remote = fileremotes.create(remote_data)
Lets say the file plugin provided some other remote that still synced file content?
</span></span></code></pre></div></blockquote><div><br></div><div>The goal is to provide separate API objects for each remote or content type that a plugin provides. So the code would look like this:</div><div><br></div><div>file_remote = fileremote.create(remote_data)</div><div>file_fancy_remote = filefancyremote.create(fancy_remote_data)</div><div><br></div><div>My current implementation does not support this, but I am working toward the above solution. <br></div></div></div></blockquote><div><br></div><div><div>I was able to achieve this. I posted some screen shots of what the docs look like here[0].</div><div><br></div><div>Docker has multiple content types. So docker bindings would provide the following objects: ContentDockerBlobsApi, ContentDockerManifestListTagsApi, ContentDockerManifestListsApi, ContentDockerManifestTagsApi, and ContentDockerManifestsApi.</div><div><br></div><div>Each of those objects would have a create(), read(), delete(), list() methods. <br></div><div><br></div><div>Do others agree that this improves the usability of the bindings?<br></div><div><br></div><div><br></div><div>[0] <a href="https://imgur.com/a/Ag7gqmj">https://imgur.com/a/Ag7gqmj</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><pre><code class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-1552284183194660336gmail-m_-7135414750268891943insert">
Justin
</span></span></code></pre>
<p>On 6/19/19 9:45 AM, Dennis Kliban wrote:<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>I didn't get a note in my email, but I did see one on in
the list archive[0]. So here is my response to it:</div>
<div><br>
</div>
<div>
<div>I agree that we could use modified templates to achieve
the same results. However, that means that we will need to
modify templates for every language we want to generate
bindings in. In both cases the generated client code will be
exactly the same. From a maintenance perspective, it is
easier to add a feature to Pulp's REST API that produces a
modified version of the OpenAPI schema. It also means that
we can always use the latest versions of the templates
shipped with openapi-generator. <br>
</div>
<div><br>
</div>
<div>The documentation site would continue to distribute an
OpenAPI schema where each Operation Id is unique. </div>
</div>
<div><br>
</div>
<div>Pulp's OpenAPI schema does not currently pass validation
because the paths are not unique. In order to use the 'href'
of each resource as the primary identifier, it was necessary
to template paths as {artifact_href}, {repository_href},
{file_content_href}, etc. This schema cannot be used to
generate server code. However, it works well when generating
client code. The non-unique operation ids would be a problem
for generating a server also. However, they don't produce
problems when generating client code.</div>
<div><br>
</div>
<div>Does this address your concerns?<br>
</div>
<div><br>
</div>
<div>[0] <a href="https://www.redhat.com/archives/pulp-dev/2019-June/msg00061.html" target="_blank">https://www.redhat.com/archives/pulp-dev/2019-June/msg00061.html</a></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 8:54
AM Dennis Kliban <<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>As pointed out in a recent issue[0], the method names
in the bindings generated from Pulp's OpenAPI schema are
unnecessarily verbose. Each method name corresponds to an
Operation Id in the OpenAPI schema. The Operation Id is
also used as an HTML anchor in the REST API docs[1]. <br>
</div>
<div><br>
</div>
<div>It is possible to generate a schema where each
Operation Id is shorter, but then the Operation Ids are
not unique and all the linking in the REST API
documentation breaks. We can avoid this problem by keeping
the long Operation Id for the schema generated for the
docs and only using short Operation Ids when generating
the schema for the bindings. <br>
</div>
<div><br>
</div>
<div>The difference in usage of the bindings can be seen
here[2]. <br>
</div>
<div><br>
</div>
<div>Is there any objection to including such a change in
time for RC 3?<br>
</div>
<div><br>
</div>
<div>[0] <a href="https://pulp.plan.io/issues/4989" target="_blank">https://pulp.plan.io/issues/4989</a> </div>
<div>[1] <a href="https://docs.pulpproject.org/en/3.0/nightly/restapi.html" target="_blank">https://docs.pulpproject.org/en/3.0/nightly/restapi.html</a></div>
<div>[2] <a href="https://pulp.plan.io/issues/4989#note-1" target="_blank">https://pulp.plan.io/issues/4989#note-1</a></div>
</div>
</blockquote>
</div>
<br>
<fieldset class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-quote-pre">_______________________________________________
Pulp-dev mailing list
<a class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a>
<a class="gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
</div>
</blockquote></div></div>
</blockquote></div></div>