On 08/27/2010 08:00 AM, Jay Pipes wrote: > On Thu, Aug 26, 2010 at 5:31 PM, Erik Carlin <[email protected]> > wrote: >> I love the idea of reusable libraries across OpenStack projects. That does >> imply a common language, which may not always be the case, but it does >> provide some dedup. > > Yep, agreed. > >> I do think each service should have language bindings. We have debated the >> idea of a single set of language bindings across services (e.g. one python >> binding for compute, object storage, and others like load balancing, dns, >> networking, etc. when they come) vs. each service being responsible for >> their own bindings. What do people think? If we prefer the former, I would >> say they should be a separate project. If they are the responsibility of >> each service team, I would say they should stay with each individual >> project. > > Each service will really just be a WSGI/REST application, so any > language that has support for REST communications should be just fine, > no? Or am I missing something? :)
Just because a service exposes a REST interface doesn't mean everything is perfectly happy. Having a library that actually models sensible things and doesn't make an end user write a crap-ton of boilerplate REST code goes a long way to making it easier to write client apps. As a person who has recently been writing apps consuming some REST services, I would _strongly_ second the suggestion to ensure there are good bindings. At a minimum we should probably provide sensible python and ruby bindings. I know there will be Java support for both swift and nova in jclouds, and if there are other exposed services that want bindings they can probably go in there. >> Thoughts? >> >> Jorge, I know you have some ideas about a binding "framework" that could be >> used to build bindings in a common manner. Could you please share your >> ideas with the group? >> >> Erik >> >> >> On 8/26/10 3:26 PM, "Pete Zaitcev" <[email protected]> wrote: >> >>> On Thu, 26 Aug 2010 15:04:01 -0400 >>> Jay Pipes <[email protected]> wrote: >>> >>>> My proposal is to create another project on Launchpad called >>>> openstack-common that will contain a Python library that standardizes >>>> and consolidates all the above-mentioned overlap and makes an >>>> easy-to-use, well-documented library of common utilities and modules >>>> for the OpenStack family of projects to use. [] >>> >>> I am not familiar with OpenStack code yet but in Hail we eventually >>> did exactly that, although not for efficiency, but because we were >>> tired of carefuly porting bugfixes. Also it allowed outside-of-family >>> programs to use the Amazon S3 C bindings without installing >>> unrelated packages. You might want to consider throwing a couple >>> of CloudFiles clients into openstack-common too. >>> >>> -- Pete >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> >> >> Confidentiality Notice: This e-mail message (including any attached or >> embedded documents) is intended for the exclusive and confidential use of the >> individual or entity to which this message is addressed, and unless otherwise >> expressly indicated, is confidential and privileged information of Rackspace. >> Any dissemination, distribution or copying of the enclosed material is >> prohibited. >> If you receive this transmission in error, please notify us immediately by >> e-mail >> at [email protected], and delete the original message. >> Your cooperation is appreciated. >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
