<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 6/20/19 8:02 AM, Dennis Kliban
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPmNiuoZvMFZ-0ERiWGMHiGSrQZUyaCVs920-=bw1sLOqpWUCA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 1:57
PM Dennis Kliban <<a href="mailto:dkliban@redhat.com"
moz-do-not-send="true">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:34 AM Dennis Kliban <<a
href="mailto:dkliban@redhat.com" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">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_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete">-</span>file_remote = fileremotes.<span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943eyecatcher">remotes_file_file_</span>create(remote_data)</span>
<span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943insert"><span class="gmail-m_-3906654651343441420gmail-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>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAPmNiuoZvMFZ-0ERiWGMHiGSrQZUyaCVs920-=bw1sLOqpWUCA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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><br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I updated my patch and removed the plugin name from the
Api object names. So the above objects are now
ContentBlobsApi, ContentManifestListTagsApi,
ContentManifestListsApi, ContentManifestTagsApi, and
ContentManifestsApi.</div>
</div>
</div>
</blockquote>
<p>I like this all, and agree it improves readability. I assume
there's no concern about plugins implementing some model with the
same name? Or i guess this could already be a problem when it
comes to model/db table names in the app itself? <br>
</p>
<p>Justin<br>
</p>
<blockquote type="cite"
cite="mid:CAPmNiuoZvMFZ-0ERiWGMHiGSrQZUyaCVs920-=bw1sLOqpWUCA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>
<div>I have 2 PRs for this change[0,1]. The use of the
bindings can be seen in both of the PR. I'd like to get
this work merged today. <br>
</div>
<div><br>
</div>
<div>[0] <a
href="https://github.com/pulp/pulpcore/pull/178"
moz-do-not-send="true">https://github.com/pulp/pulpcore/pull/178</a>
<br>
</div>
<div>[1] <a
href="https://github.com/pulp/pulp-openapi-generator/pull/18"
moz-do-not-send="true">https://github.com/pulp/pulp-openapi-generator/pull/18</a></div>
</div>
<div><br>
</div>
<div> <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>
<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"
target="_blank" moz-do-not-send="true">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>
<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_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">https://pulp.plan.io/issues/4989</a> </div>
<div>[1] <a
href="https://docs.pulpproject.org/en/3.0/nightly/restapi.html"
target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">https://pulp.plan.io/issues/4989#note-1</a></div>
</div>
</blockquote>
</div>
<br>
<fieldset
class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-quote-pre">_______________________________________________
Pulp-dev mailing list
<a class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank" moz-do-not-send="true">Pulp-dev@redhat.com</a>
<a class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank" moz-do-not-send="true">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 1:57
PM Dennis Kliban <<a href="mailto:dkliban@redhat.com"
moz-do-not-send="true">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:34 AM Dennis Kliban <<a
href="mailto:dkliban@redhat.com" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">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_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943delete">-</span>file_remote = fileremotes.<span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943eyecatcher">remotes_file_file_</span>create(remote_data)</span>
<span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943insert"><span class="gmail-m_-3906654651343441420gmail-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"
target="_blank" moz-do-not-send="true">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>
<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_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943diff gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943syntaxhl"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943CodeRay"><span class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943line gmail-m_-3906654651343441420gmail-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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">https://pulp.plan.io/issues/4989</a> </div>
<div>[1] <a
href="https://docs.pulpproject.org/en/3.0/nightly/restapi.html"
target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">https://pulp.plan.io/issues/4989#note-1</a></div>
</div>
</blockquote>
</div>
<br>
<fieldset
class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-quote-pre">_______________________________________________
Pulp-dev mailing list
<a class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com" target="_blank" moz-do-not-send="true">Pulp-dev@redhat.com</a>
<a class="gmail-m_-3906654651343441420gmail-m_-1552284183194660336gmail-m_-7135414750268891943moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev" target="_blank" moz-do-not-send="true">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>