[Openstack] OpenStack core components library

Jay Pipes jaypipes at gmail.com
Mon Aug 30 15:34:13 UTC 2010


Done:

https://launchpad.net/openstack-common

Rick, feel free to change the branding to the openstack images, etc...

-jay

On Mon, Aug 30, 2010 at 11:27 AM, Rick Clark <rick at openstack.org> wrote:
> +1 This is the only reasonable thing to do.
>
>
> On 08/30/2010 09:41 AM, Jay Pipes wrote:
>> OK, so is everyone cool with me creating a new project called
>> openstack-common under the openstack umbrella?  This project would be
>> specifically for *Python* common library and utilities.
>>
>> We got a little off-track with discussing bindings (it's a great
>> topic, but not necessarily related to a common Python component
>> library :) )
>>
>> -jay
>>
>> On Sat, Aug 28, 2010 at 5:12 PM, Gregory Holt <gholt at rackspace.com> wrote:
>>> Okay, I guess I'll just wait for things to start becoming more concrete and then maybe I'll see what you're getting at. If we call one a language-binding framework and the other a language binding, it's all the same to me. :)
>>>
>>> On Aug 28, 2010, at 2:38 PM, Jorge Williams wrote:
>>>
>>>>
>>>> Okay, I think we're sorta talking about the same thing.  The part of the code that handles the boiler-plate stuff (what you call the low-level binding) I see as being  the language-binding framework.  The language binding that we share with customers is written on top of that. We can certainly distribute the framework, and develop it in an open source manner, but I see most of our users simply using the binding.
>>>>
>>>> If we follow a basic set of standards for handling collections, error conditions, rate limiting, etc. the only thing that should differ between services are the entity types and the URLs.    We can all share the same basic boiler plate code. The binding just adds the specifics for the individual service.  In a very real sense we are all using the  same underlying base  protocol at that point.  Drivers are written to handle the problem of interacting with varying protocols.  If we're all speaking the same protocol, I don't see the need for a driver.  I'd much rather we standardize at the protocol level then to expect service teams to produce compatibility drivers for each service.  Especially when you consider that there are additional benefits to us standardizing at the protocol anyway.
>>>>
>>>> -jOrGe W.
>>>>
>>>>
>>>> On Aug 28, 2010, at 1:26 PM, Gregory Holt wrote:
>>>>
>>>>> On Aug 28, 2010, at 12:29 PM, Jorge Williams wrote:
>>>>>
>>>>>> I strongly disagree with the idea of us maintaining multiple same-language bindings for a single service. This is going lead to confusion and additional work.
>>>>>
>>>>>
>>>>> I guess we'll have to agree to strongly disagree. :)
>>>>>
>>>>> In my mind, one would write the low-level bindings first and then the high-level bindings which would just wrap the low-level ones in a more abstracted way; so I guess I don't really see the additional work. As far as confusion, I don't see confusion around an ORM using a lower-level DB-API/JDBC driver. Providing both is useful. If you provide the ORM and not the driver, that's frustrating.
>>>>>
>>>>> But, honestly, if there are no official low-level bindings for Swift in Python, I'll definitely be maintaining my own. See swift/common/client.py for the boiler-plate I don't want to have to repeat each time.
>>>>>
>>>>> Now maybe client.py is the type of bindings you're talking about and I'm just misinterpreting your idea as even higher-level. In that case, I'm arguing about the wrong thing. :)
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>




More information about the Openstack mailing list