Open Stack

On Mon, Jan 3, 2011 at 10:00 PM, John Dickinson
<john.dickinson at rackspace.com> wrote:
> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:
>>
>> API/Service Protocol: RESTful interfaces specific to each service. Each service will present a Public API, a Management API, and optionally, a Notification API. The set and format of the service interface calls define the Service Protocol.
>
>>  OpenStack Programming Model: The set of functions and calls that OpenStack Application Developers will interact with. These will be presented through various language bindings, the only restriction is that consistency between implementations in maintained.
>
>>  The key concept being proposed is that the developers that will be interacting with the OpenStack services will not interact directly with the service API’s, but rather will have a set of published language bindings that define the programming model. This does not preclude direct service calls, but this will be discouraged in favor of using the bindings. The bindings will be considered the “Nova API” for all intents and purposes.
>
> Based on our experience with Cloud Files (HTTP API + 5 language bindings), I don't agree.
>
> I think that language bindings are very important, but they add extra baggage to the project. I would think that we should encourage openstack users (ie devs) to use provided bindings, but see them as second-class citizens in relation to the direct API. Language bindings will provide a good basis for most projects, but the direct API approach will allow the user (dev) to get better performance or newer features.
>
> Problems with a "language bindings as primary" approach:
>
> 1) Features are delayed because they must be added to all bindings before being officially release/supported. This slows down development
>
> 2) The project requires active devs with good knowledge of many languages across the dev team. As devs come and go, this makes it difficult to keep good language bindings.
>
> 3) Different languages generally have different ways of doing things. This leads to differentiation between the bindings and difficulty in keeping consistency. For example, how should one implement concurrency with Python, Java, PHP, and C language bindings? threads? processes? coroutines? This extends to the different libraries and toolkits available in different languages. Even within one language you can have highly passionate views on how to do it The Right Way (eg twisted vs eventlet in Python).
>
> I would suggest that Openstack projects should have language bindings and these bindings should be written well and maintained. But the direct API to the service (HTTP or otherwise) should always take precedence. I know the example was for nova, but since I have experience with swift, I will use an example there. Large files (5GB+) are supported in Bexar, but they are not included in any language bindings. Initially, until the language bindings are updated, the only way to get them is to use the HTTP API directly. This should not prevent the feature from being released in Bexar, nor should Bexar require language binding support for large files in swift before release.

++

HTTP API should be primary development focus for new features and
binding maintainers can/should update bindings after the canonical
HTTP API is enhanced.  This is how the vast majority of open source
projects function -- i.e. the pick a canonical API (typically
REST/HTTP for webby-type projects and C API for non webby-type
projects) and then update language bindings afterwards.

-jay