openstack team mailing list archive
Mailing list archive
Re: OpenStack core components library
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.
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. :)