<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.5pt;
        font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>Good discussion, and an overwhelming no vote on requiring OpenStack language bindings to be first-class constructs and the preferred method for publishing our programming model.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I do believe that we should have/need an aggregation layer for services that expose multiple services/functions (such as with Nova, containing VM, VV, VI, and VN services). This will allow us to have a singular endpoint (likely per geographic region, but that is a subject for follow-on posts) for OpenStack application developers and sysadmins. This will be versioned, can supply necessary orchestration, provide transaction support as necessary, and allow as much concurrency as we choose to allow. We also need a mechanism to allow service registration and discovery, to allow for deployment specific topologies (either core services that are not available, or additional services that have been added).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>As the programming model, API aggregation, and required logic sits above, and consumes, the lower level service APIs it makes sense to propose this be a project on its own. This team could own the API, CLI, and associated application/sysadmins documentation (working with Anne). This team can also be the focal point for the creation of the language bindings.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Low level service APIs continue to be owned and developed by each of the service teams.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Thoughts?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><img width=401 height=419 id="Picture_x0020_1" src="cid:image002.jpg@01CBAC14.75B1EFB0"><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-John<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: openstack-bounces+john=openstack.org@lists.launchpad.net [mailto:openstack-bounces+john=openstack.org@lists.launchpad.net] On Behalf Of Thierry Carrez<br>Sent: Tuesday, January 04, 2011 7:53 AM<br>To: openstack@lists.launchpad.net<br>Subject: Re: [Openstack] [RFC] OpenStack Programming Model Framework<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>John Dickinson wrote:<o:p></o:p></p><p class=MsoPlainText>> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:<o:p></o:p></p><p class=MsoPlainText>>>  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.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> Based on our experience with Cloud Files (HTTP API + 5 language bindings), I don't agree.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> 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.<o:p></o:p></p><p class=MsoPlainText>> [...]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I tend to agree with John D.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>If you expose language bindings as the recommended way of interacting,<o:p></o:p></p><p class=MsoPlainText>you have to keep them current. That means you have to choose a very<o:p></o:p></p><p class=MsoPlainText>restricted set of languages and commit resources to keeping them current.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>If the API is exposed as the "pure" way of interacting, you admit that<o:p></o:p></p><p class=MsoPlainText>language bindings can be slightly out of date. You can pick one or two<o:p></o:p></p><p class=MsoPlainText>reference language bindings and maintain them reasonably current, and<o:p></o:p></p><p class=MsoPlainText>leverage language-specific communities to cover for the rest of the<o:p></o:p></p><p class=MsoPlainText>landscape...<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>You end up having better language coverage for less effort. I'm probably<o:p></o:p></p><p class=MsoPlainText>missing the advantage of reducing direct API exposure...<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-- <o:p></o:p></p><p class=MsoPlainText>Thierry Carrez (ttx)<o:p></o:p></p><p class=MsoPlainText>Release Manager, OpenStack<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>_______________________________________________<o:p></o:p></p><p class=MsoPlainText>Mailing list: https://launchpad.net/~openstack<o:p></o:p></p><p class=MsoPlainText>Post to     : openstack@lists.launchpad.net<o:p></o:p></p><p class=MsoPlainText>Unsubscribe : https://launchpad.net/~openstack<o:p></o:p></p><p class=MsoPlainText>More help   : https://help.launchpad.net/ListHelp<o:p></o:p></p></div></body></html>