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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
