<div dir="ltr"><div><div>>I did notice, however, that neutronclient is<br>
conspicuously absent from the Work Items in the blueprint's Whiteboard.<br></div>It will surely be added later. We already working on several things in parallel and we will add neutronclient soon.<br><br>>I would love to see a bit more detail on the structure of the 
lib(s), the blueprint really doesn't discuss the 
design/organization/intended API of the libs.  For example, I would hope
 the distinction between the various layers of a client stack don't get 
lost, i.e. not mixing the low-level REST API bits with the higher-level 
CLI parsers and decorators.
<div></div><div>>Does the long-term goals include a common caching layer?<br><br></div><div>Distinction between client layers won't get lost and would only be improved. My basic idea is the following:<br></div><div>
1) Transport layer would handle all transport related stuff - HTTP, JSON encoding, auth, caching, etc.<br></div><div>2) Model layer (Resource classes, BaseManager, etc.) will handle data representation, validation<br></div>
<div>3) API layer will handle all project specific stuff - url mapping, etc. (This will be imported to use client in other applications)<br></div><div>4) Cli level will handle all stuff related to cli mapping - argparse, argcomplete, etc.<br>
</div><br>>I believe the current effort referenced by the blueprint is focusing on 
moving existing code into the incubator for reuse, to make it easier to 
restructure later. <span style="font-family:arial,sans-serif">Alexei, do I have that correct?<br></span></div><span style="font-family:arial,sans-serif">You are right. The first thing we do is try to make all clients look/work in similar way. After we'll continue our work with improving overall structure.<br>
</span><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/16 Noorul Islam K M <span dir="ltr"><<a href="mailto:noorul@noorul.com" target="_blank">noorul@noorul.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> writes:<br>

<br>
> Several people have mentioned to me that they are interested in, or<br>
> actively working on, code related to a "common" client library -- something<br>
> meant to be reused directly as a basis for creating a common library for<br>
> all of the openstack clients to use. There's a blueprint [1] in oslo, and I<br>
> believe the keystone devs and unified CLI teams are probably interested in<br>
> ensuring that the resulting API ends up meeting all of our various<br>
> requirements.<br>
><br>
> If you're interested in this effort, please subscribe to the blueprint and<br>
> use that to coordinate efforts so we don't produce more than one common<br>
> library. ;-)<br>
><br>
<br>
</div>Solum is already using it <a href="https://review.openstack.org/#/c/58067/" target="_blank">https://review.openstack.org/#/c/58067/</a><br>
<br>
I would love to watch this space.<br>
<br>
Regards,<br>
Noorul<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>