I'm a big proponent of standalone clients since Horizon has to consume all of 
them. Big +1 there.

However, there seems to be a split in the community as to what the clients 
should look like:

  * Glance and Quantum's clients are very flat things that basically just parse 
the JSON data returned and hand back dictionaries.
  * Novaclient and Keystoneclient follow an object-oriented paradigm with 
manager interfaces and pretty wrapper classes.
  * Cloudfiles has objects but no managers, while Swift's internal client is 
the dict style.

Having to work with all of these, some consistency would be nice. Moreover, if 
we could agree on a consistency it would allow us to create a common client 
base library that individual projects could then build from instead of starting 
from scratch each time.

All the best,

    - Gabriel

> -----Original Message-----
> From: openstack-bounces+gabriel.hurley=nebula....@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula....@lists.launchpad.net] On Behalf Of John
> Dickinson
> Sent: Monday, February 13, 2012 7:53 AM
> To: Chmouel Boudjnah
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] python-swiftclient?
> 
> 
> On Feb 13, 2012, at 8:29 AM, Chmouel Boudjnah wrote:
> >
> >
> > What do you think if we :
> >
> > - split swift.common.client to its own.
> > - have bin/swift import that package and shipped with it.
> > - have a comprehensive test suite covering the CLI and the library.
> > - have some proper PIP release for all the projects to depend on it.
> 
> 
> +1
> 
> Also, you may want to look at https://github.com/gholt/swiftly
> 
> --John


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to