Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things:
Keeping all the clients physically separate/combining them in to a single library. Two things here: In case of combining them, what exact project are we considering? If this list is limited to core projects like nova and keystone what policy could we have for other projects to join this list? (Incubation, graduation, something else?) In terms of granularity and easiness of development I’m for keeping them separate but have them use the same boilerplate code, basically we need a OpenStack Rest Client Framework which is flexible enough to address all the needs in an abstract domain agnostic manner. I would assume that combining them would be an additional organizational burden that every stakeholder would have to deal with. Has anyone ever considered an idea of generating a fully functional REST client automatically based on an API specification (WADL could be used for that)? Not sure how convenient it would be, it really depends on a particular implementation, but as an idea it could be at least thought of. Sounds a little bit crazy though, I recognize it :). Renat Akhmerov On 16 Jan 2014, at 11:52, Chmouel Boudjnah <chmo...@enovance.com> wrote: > On Thu, Jan 16, 2014 at 8:40 PM, Donald Stufft <don...@stufft.io> wrote: > > On Jan 16, 2014, at 2:36 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > >> 2) major overhaul of client libraries so they are all based off a common >> base library. This would cover namespace changes, and possible a push to >> move CLI into python-openstackclient > This seems like the biggest win to me. > > > +1 > > Chmouel. > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
