On Mon, Jan 3, 2011 at 10:00 PM, John Dickinson <john.dickin...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
