<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div><br>On Nov 11, 2013, at 2:53 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Mon, Nov 11, 2013 at 12:01 AM, Clayton Coleman <span dir="ltr"><<a href="mailto:ccoleman@redhat.com" target="_blank">ccoleman@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The implication I heard from the session is the command infrastructure and client code have or will have a well defined interface from the framework, although I haven't looked through current state enough to say that's totally true today.  If that interface is in place we certainly would be better isolated from upstream.<br>
</blockquote><div><br></div><div>OSC has a very simple plugin mechanism that is little more than pre-defined entry point groups that are scanned for additional commands.  That works but doesn't properly leverage the desirable common bits, such as auth, that are available to the built-in clients.  Enhancing this has not been a high priority before now but needs to be done.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess it depends where we want to spend our focus as well - do we write something that in the long run we'd end up porting, or benefit from the work the common client is doing (doc, common patterns, keystone auth work with x509 and potentially Kerberos, bash completion, etc) as well as help them out.<br>
</blockquote><div><br></div><div>I'd suggest you focus on putting together a clean and well-defined library API that implements your REST API.  Consider that work is going on to refactor the implementation of these layers in existing clients and that some of the library APIs will be changing.  Specifically, the first of these efforts is a much-needed cleanup of the Identity Auth interfaces and the migration of existing clients to use that rather than their own embedded auth.</div>
<div><br></div><div>Please don't just copy one of the existing clients, down that path lies madness.</div></div></div></div></div></blockquote><div><br></div><div>I know in the session a "generic" API client lib was mentioned, is that in a branch somewhere to highlight the things that were common across a lot of API libs?  Or knowing your opinion of the "best" client to copy.  :)</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div>dt</div></div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>

</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div></body></html>