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
