<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 6, 2014 at 10:24 PM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 5 March 2014 03:44, Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com">cbkyeoh@gmail.com</a>> wrote:<br>
> But this plan is certainly something I'm happy to support. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">One extra thing we need to consider, how to deal with new APIs while<br>
</div>
we go through this transition?<br>
<br>
I don't really have any answers to hand, but I want v3 to get released<br>
ASAP, and I want people to easily add API features to Nova. If the<br>
proxy is ready early, maybe we could have people implement only v3<br>
extensions, then optionally add v2 extension that just uses wraps the<br>
v2 proxy + v3 extensions.<br>
<div class=""><br></div></blockquote><div><br></div><div>So pretty much any extension which is added now (or those that have gone in during Icehouse) should <br>offer an API which is exactly the same. There's no excuse for divergence so what you suggest is most likely<br>
quite doable. We might not even need a proxy in some cases to make it available in the v2 namespace.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> - I'm not sure how this affects how we approach the tasks work. Will<br>
> need to think about that more.<br>
<br>
</div>+1<br>
<br>
Its a thread of its own, but I think improving instance-actions, still<br>
leaving tasks for v3, might be the way forward.<br>
<br>
While we need to avoid feature creep, I still think if we add tasks<br>
into v3 in the right way, it could be what makes people move to v3.<br>
<br></blockquote><div><br></div><div>Yea we really need to flesh out what we want from tasks long term.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One more thing... I wonder if all new extensions should be considered<br>
"experimental" (or version 0) for at least one cycle. In theory, that<br>
should help us avoid some of the worst mistakes when adding new APIs.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, so this I think is a similar suggestion to being able to have extensions first drop<br>into a holding area outside of Nova. Because the whole freeze deadline rush is a recipe for making<br>
</div><div>compromises around the API that we don't want to live with for the long term but do so<br>because we want a feature to merge soon. But I think whatever approach we take it needs<br>to come with the possibility that if its not fixed up in a reasonable time, it may get removed.<br>
</div><div>So we don't end up with a large pool of experimental things.<br></div><div><br></div><div>As an aside, I think we need to improve the process we use for API related features. Because a lot of the<br></div><div>
problems that get picked up during code review could have been avoided if we had a better review<br>earlier on that just focussed on the API design independent of implementation and Nova internals.<br></div><div><br></div>
<div>Chris<br></div><br></div></div></div>