+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 <[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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
