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 <[email protected]> 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 : [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
