On Wed, Aug 3, 2011 at 7:52 AM, Tyler Smith <tyles...@cisco.com> wrote:
> Hi everyone, > > I agree that allowing extensions to core objects would allow for the most > intuitive API. It would seem to me that clients talking to different plugins > would need to do very different things. I don't see a very well functioning > "generic" client that work well with multiple plugins. The api client > library that was just merged in is low-level enough that it should be able > to work fine with any plugin (it just serializes, sends, and deserializes > arbitrary data). However a full functioning client (such as the CLI), would > be very difficult to make work with different Quantums with different > extensions. > Hi Tyler, If we go this route, I still hope that people will be able to make "generic" clients that manage the "core" functionality of Quantum regardless of the plugin (I would expect that the dashboard will work this way). It may, however, be that we tell people to write these clients in such a way that they ignore any fields that they do not understand, thus, so that the client doesn't choke on any extra "data extensions". > > It would seem to me that the best route to go would be add support to the > api client to check the extension running on Quantum, and implement fuller > client applications only for specific extensions. (e.g. MyNewHostingCompany > may build many plugins that their various Quantum instances use, and build a > single client that works with all of them) > Yes, no matter what we decide on data extensions in particular, I definitely would like to see the client be able to confirm what API extensions are running. I would imagine a flow like: conn = create_api_connection() conn.confirm_extension_support("Cisco-awesome-extension1") conn.confirm_extension_support("Cisco-awesome-extension2") conn.create_network() conn.create_port() // perhaps this call takes another field when using cisco-awesome-extension1, if we support data extension of default objects conn.do_request("v1.0/csco/do_something_awesome2", { "foo" : "bar"}) // do_request allows you to access entirely new calls introduced by an API extension Thoughts? Dan > I may be way off track here, but this would seem to me to be the best > route. > > -Tyler > > > On 8/3/2011 9:07 AM, Salvatore Orlando wrote: > >> >> Hi Ying, >> >> I too think the approach proposed by Jorge will avoid clashes between >> different extensions. >> >> I don’t have anything in principle against extending core API entities. My >> only concern is “portability” of client apps. >> >> If I write my application using the core API, and I get extended >> attributes in responses (or I’m supposed to specify extended attributes in >> requests), then I cannot guarantee that my client app continues to work when >> the someone swaps RAX-PIE with another extension. This might imply that >> client applications should somehow be aware of extensions. >> >> For instance, I would structure the previous example as follows: >> >> XML: >> >> <image >> xmlns="http://docs.**rackspacecloud.com/servers/**api/v1.0<http://docs.rackspacecloud.com/servers/api/v1.0> >> " >> >> id="1" name="CentOS 5.2" >> >> serverId="12" >> >> updated="2010-10-10T12:00:00Z" >> >> created="2010-08-10T12:00:00Z" >> >> status="ACTIVE" >> >> /> >> >> <RAX-PIE:image xmlns:RAX-PIE="http://docs.**rackspacecloud.com/servers/** >> api/ext/pie/v1.0<http://docs.rackspacecloud.com/servers/api/ext/pie/v1.0> >> " >> >> RAX-PIE:id="ext_res_id" >> >> RAX-PIE:ref-id="1" >> >> RAX-PIE:shared="true" >> >> /> >> >> JSON: >> >> { >> >> "image" : { >> >> "id" : 1, >> >> "name" : "CentOS 5.2", >> >> "serverId" : 12, >> >> "updated" : "2010-10-10T12:00:00Z", >> >> "created" : "2010-08-10T12:00:00Z", >> >> "status" : "ACTIVE", >> >> } >> >> } >> >> { >> >> "RAX-PIE:image" : { >> >> "id" : "ext_res_id", >> >> "ref-id" : "1", >> >> "RAX-PIE:shared" : true >> >> } >> >> } >> >> In this way a client for the Core API will always get the responses the >> core API is supposed to receive, whereas a client specifically written for >> RAX-PIE extension will retrieve the “extended” image resource and then the >> original image resource through the ref-id attribute. >> >> Anyway, I don’t have a very strong opinion on this topic, and I also agree >> that allowing direct extension of resources has its own benefits. If the >> majority agrees on allowing resource extensions, then I will be happy to >> have them J. It would be good to receive feedback from Tyler and the other >> guys who worked on the client library as well. >> >> Cheers, >> >> Salvatore >> >> > -- > Mailing list: > https://launchpad.net/~**netstack<https://launchpad.net/~netstack> > Post to : netstack@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~**netstack<https://launchpad.net/~netstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp