<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">+1 on everything here.<br>
      <br>
      My only&nbsp; comments:<br>
      <br>
      Point 1)<br>
      <br>
      We have many different consumers (personas) of the API.&nbsp; Some may
      simply want to build images, others may want to launch and so on.&nbsp;
      The difficulty here is putting a weighting on each persona i.e. is
      one persona more important than the other?<br>
      <br>
      Ideally we would get feedback from existing customers and build a
      priority list.<br>
      <br>
      If we can't get hold of this information, an alternate approach
      could be we look at core functionality of Aeolus? i.e. Why are we
      better than just using deltacloud, or imagefactory? and focus our
      efforts on the bits of each persona that are associated with this.<br>
      <br>
      Point iii)<br>
      <br>
      Absolutely we do not want to blindly copy the database schema.&nbsp; We
      should be very careful and consider each resource we aim to
      expose.&nbsp; Some of the information / models are for internal use and
      don't make sense to an end user.<br>
      <br>
      Point iv)<br>
      <br>
      +1 - In fact the initial implementation was done in this way.&nbsp; But
      as the UI around image management started being built many methods
      were reimplemented (rather than simply calling the API methods)
      for the same functionality.&nbsp; Controillers we ended up with
      duplicated code and the thing was a mess.&nbsp; In the end we ended up
      moving API + UI into single controlllers.<br>
      <br>
      I actually think that the UI controllers should sit on top of the
      API controllers.&nbsp; Even if the controllers are simply making native
      calls (rather than ReST).&nbsp; It allows the components to be
      separated out.&nbsp; <br>
      <br>
      To me this makes sense on a couple levels.&nbsp; <br>
      <ul>
        <li>The UI guys can focus on what they do best "Building UIs",</li>
        <li>It allows customers to deploy only the API (feedback from
          existing users has hinted that they do not use the UI at all
          and only use the API).&nbsp; <br>
        </li>
        <li>We can componentise the UI.&nbsp; Only deploy the bits of the UI
          that people want + the API (for example self-service portal)<br>
        </li>
        <li>The UI and the API fucntionality is very different.&nbsp; The UI
          is meant for end user consumption and as such has totally
          different workflows, combines information from many
          unassociated resources and holds state.&nbsp; All very different
          from a ReST API.</li>
      </ul>
      <p>All IMHOs,<br>
      </p>
      <p>Thanks<br>
      </p>
      <p>Martyn<br>
      </p>
      <p><br>
      </p>
      <br>
      <br>
      On 01/16/2013 02:09 PM, Martin Povolny wrote:<br>
    </div>
    <blockquote cite="mid:20130116140912.GC9735@piskot.brq.redhat.com"
      type="cite">
      <pre wrap="">While I am at the writing mood today I would like to say a couple of
things to the API. All these are IMHOs so let's pretend there's a IMHO
in front of each point.

i) the API implementation should start with what the consumer needs or
wants

1) the client would want to start with launching things (deployment)
2) next the client would want to check if the thing he wanted to run
actually runs
3) next the client may want something else like list all the stuff he
has

ii) the API needs a client to check it's actually good

I already wrote in a different thread that freezing the API before
verifying that it's actually usable by having at least one client is not
a good idea. In our project probably the first client is the CLI.

iii) the API structure need not copy the internal structure of the
project (being it the models or the controllers)

Actually the API should hide the implementation details as much as
possible and it should be structured in a way that is logical from the
consumer point of view.

iv) from the above it's obvious that having the API in the same
controllers that serve the WUI might not always be the best way to do
not only in terms of spaghetti popularity.

These are just IMHOs, but thanks for reading up to this point!

</pre>
    </blockquote>
    <br>
  </body>
</html>