<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" 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="diff syntaxhl"><span class="CodeRay"><span class="line delete"><span class="delete">-</span>file_remote = fileremotes.<span class="eyecatcher">remotes_file_file_</span>create(remote_data)</span>
<span class="line insert"><span class="insert">+</span>file_remote = fileremotes.create(remote_data)

Lets say the file plugin provided some other remote that still synced file content?

Justin
</span></span></code></pre>
    <p>On 6/19/19 9:45 AM, Dennis Kliban wrote:<br>
    </p>
    <blockquote type="cite"
cite="mid:CAPmNiupv8SpEviWSCe7_D2r7wp0FVFyfEZu1JvhfbC7=RDhi5g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Pulp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
    </blockquote>
  </body>
</html>