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.
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)
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";
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";
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
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
