openstack team mailing list archive
Mailing list archive
Re: OpenStack core components library
On Aug 28, 2010, at 11:44 AM, Gregory Holt wrote:
> On Aug 28, 2010, at 11:03 AM, Jorge Williams wrote:
>> I see standardization as being extremely beneficial. Having a common language framework is one example of how standardization can help us, but it's important to also think of this from the perspective of our clients -- why should they have to learn 10 different ways of doing the same thing?
> Having standard higher level bindings is fine as long as there are also domain-specific lower level bindings. Think of it like ORM vs. direct SQL. Many (most?) applications are fine with an ORM, but it gets really frustrating for other applications if that's all that's available.
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. A language binding should offer access to all features of the underlying protocol. Offering consistency in how one manages exceptions, or iterates through lists, should not get in the way of that. A developer is welcomed to make direct HTTP requests if they want to get at the service at a lower level.
Please, let's have a single official binding per language.
> But aside from all that, I don't think bindings really belong lumped into an OpenStack Commons project but instead as a bindings project per service (such as Swift Bindings as a project, comprised of packages for each of the languages supported). The main reason for a project separate from the service is that bindings almost always have a quicker release schedule.
> In my opinion, keeping standard behaviors in the higher level bindings should be done with an outside specification, I suppose such could live in OpenStack Commons just fine, but likely wouldn't have any code, or very little, directly associated with it.
I agree that there may be the need for a separate language binding specification. That said, in order for this to be successful there needs to be a base set of functionality and some level of consistency between services.