<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 3:21 AM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> If necessary the tasks work could be done solely as an extension, but I<br>
> would really prefer to avoid that so I'll get this ball rolling quickly.<br>
<br>
</div>I agree that doing it as a bolt-on to v3 would be significantly less<br>
favorable than making it an integrated feature of the API. IMHO, if a<br>
server create operation doesn't return a task, then we failed, as that<br>
is (to me) one of the primary cases where a task object is important.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>So the server create operation currently has a flag to say whether to return a bunch of information<br>about the server being created (although we don't yet know if it will succeed), OR return<br>
a reservation_id which can then be used as a filter for getting information about a server.<br><br></div><div>If we made this reservation_id just happen to be the same as the task id handle returned then I think this<br>would be a pretty clean change (I don't know how this fits into the current design?). The existing<br>
reservation_id is a bit tasky-looking already.<br><br></div>Chris<br></div></div></div>