<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
George,<br>
<br>
Thanks for the comments, they make a lot of sense. There is a
Glance team meeting on Thursday where we would like to push a bit
further on this. Would you mind sending in a few more details?
Perhaps a sample of what your ideal layout would be? As an example,
how would you prefer actions are handled that do not effect a
currently existing resource but ultimately create a new resource
(for example the import action).<br>
<br>
Thanks!<br>
<br>
John<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/11/13, 8:05 PM, George Reese
wrote:<br>
</div>
<blockquote
cite="mid:950770F6-7FCF-451C-B0B1-C9D5D6105373@imaginary.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I was asked at the OpenStack Summit to look at the Glance Tasks,
particularly as a general pattern for other asynchronous
operations.
<div><br>
</div>
<div>If I understand Glance Tasks appropriately, different
asynchronous operations get replaced by a single general purpose
API call?</div>
<div><br>
</div>
<div>In general, a unified API for task tracking across all kinds
of asynchronous operations is a good thing. However, assuming
this understanding is correct, I have two comments:</div>
<div><br>
</div>
<div>#1 A consumer of an API should not need to know a priori
whether a given operation is “asynchronous”. The asynchronous
nature of the operation should be determined through a response.
Specifically, if the client gets a 202 response, then it should
recognize that the action is asynchronous and expect a task in
the response. If it gets something else, then the action is
synchronous. This approach has the virtual of being proper HTTP
and allowing the needs of the implementation to dictate the
synchronous/asynchronous nature of the API call and not a fixed
contract.</div>
<div><br>
</div>
<div>#2 I really don’t like the idea of a single endpoint
(/v2/tasks) for executing all tasks for a particular OpenStack
component. Changes should be made through the resource being
impacted.</div>
<div><br>
</div>
<div>-George</div>
<div><br>
<div>
<div>
<div>--</div>
<div>George Reese (<a moz-do-not-send="true"
href="mailto:george.reese@imaginary.com" target="_blank">george.reese@imaginary.com</a>)<br>
t: @GeorgeReese m: <a moz-do-not-send="true"
href="tel:%2B1%28207%29956-0217" value="+12079560217"
target="_blank">+1(207)956-0217</a> Skype:
nspollution</div>
</div>
<div><br>
</div>
<br class="Apple-interchange-newline">
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>