You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Paul Querna <pa...@querna.org> on 2010/04/23 21:00:16 UTC
[libcloud] "extended" APIs
Hi,
Right now we have several drivers that have more API calls available,
than what is in the standardized libcloud API.
I think we should embrace these, and let drivers be more useful to
people, and if there is ever enough drivers doing something, we should
move the function to a 'standard' API.
I think they do need to be clear to a user/developer that a specific
API is an extension though, and isn't reliable between different
providers, so I believe we should require two things:
* All extensions have a specific prefix. For example "ex_", would
mean, "ex_resize_node".
* In the documentation for an extension function, it should include
something like:
@warning This is a non-standard extension API, and only works
for driver X.
Thoughts?
Thanks,
Paul
Re: [libcloud] "extended" APIs
Posted by Paul Querna <pa...@querna.org>.
On Fri, Apr 23, 2010 at 12:58 PM, Paul Querna <pa...@querna.org> wrote:
> On Fri, Apr 23, 2010 at 12:20 PM, Ian Bicking <ia...@gmail.com> wrote:
>> On Fri, Apr 23, 2010 at 2:00 PM, Paul Querna <pa...@querna.org> wrote:
>>
>>> Right now we have several drivers that have more API calls available,
>>> than what is in the standardized libcloud API.
>>>
>>> I think we should embrace these, and let drivers be more useful to
>>> people, and if there is ever enough drivers doing something, we should
>>> move the function to a 'standard' API.
>>>
>>> I think they do need to be clear to a user/developer that a specific
>>> API is an extension though, and isn't reliable between different
>>> providers, so I believe we should require two things:
>>> * All extensions have a specific prefix. For example "ex_", would
>>> mean, "ex_resize_node".
>>> * In the documentation for an extension function, it should include
>>> something like:
>>> @warning This is a non-standard extension API, and only works
>>> for driver X.
>>>
>>> Thoughts?
>>>
>>
>> Seems reasonable. Should this also be extended to non-standard arguments to
>> standard methods?
>
> +1, definitely, that hadn't occurred to me, but that is one of the
> pain points we have felt a few times with some drivers and
> non-standard arguments.
>
I've done this in trunk, and I believe I've updated all of the
driver's create_node docs to include their extensions.
It was lots of string moving, but all the tests pass, but lemme know
if you notice any regressions.
Thanks,
Paul
Re: [libcloud] "extended" APIs
Posted by Paul Querna <pa...@querna.org>.
On Fri, Apr 23, 2010 at 12:20 PM, Ian Bicking <ia...@gmail.com> wrote:
> On Fri, Apr 23, 2010 at 2:00 PM, Paul Querna <pa...@querna.org> wrote:
>
>> Right now we have several drivers that have more API calls available,
>> than what is in the standardized libcloud API.
>>
>> I think we should embrace these, and let drivers be more useful to
>> people, and if there is ever enough drivers doing something, we should
>> move the function to a 'standard' API.
>>
>> I think they do need to be clear to a user/developer that a specific
>> API is an extension though, and isn't reliable between different
>> providers, so I believe we should require two things:
>> * All extensions have a specific prefix. For example "ex_", would
>> mean, "ex_resize_node".
>> * In the documentation for an extension function, it should include
>> something like:
>> @warning This is a non-standard extension API, and only works
>> for driver X.
>>
>> Thoughts?
>>
>
> Seems reasonable. Should this also be extended to non-standard arguments to
> standard methods?
+1, definitely, that hadn't occurred to me, but that is one of the
pain points we have felt a few times with some drivers and
non-standard arguments.
Re: [libcloud] "extended" APIs
Posted by Ian Bicking <ia...@gmail.com>.
On Fri, Apr 23, 2010 at 2:00 PM, Paul Querna <pa...@querna.org> wrote:
> Right now we have several drivers that have more API calls available,
> than what is in the standardized libcloud API.
>
> I think we should embrace these, and let drivers be more useful to
> people, and if there is ever enough drivers doing something, we should
> move the function to a 'standard' API.
>
> I think they do need to be clear to a user/developer that a specific
> API is an extension though, and isn't reliable between different
> providers, so I believe we should require two things:
> * All extensions have a specific prefix. For example "ex_", would
> mean, "ex_resize_node".
> * In the documentation for an extension function, it should include
> something like:
> @warning This is a non-standard extension API, and only works
> for driver X.
>
> Thoughts?
>
Seems reasonable. Should this also be extended to non-standard arguments to
standard methods?
--
Ian Bicking | http://blog.ianbicking.org
Re: [libcloud] "extended" APIs
Posted by Adrian Cole <fe...@gmail.com>.
Good idea, Paul. Mixing and matching in the same class may get messy,
though. Perhaps you could expose a provider interface where all usage is
implicitly proprietary.
Wdyt?
Adrian
On Apr 23, 2010 12:00 PM, "Paul Querna" <pa...@querna.org> wrote:
Hi,
Right now we have several drivers that have more API calls available,
than what is in the standardized libcloud API.
I think we should embrace these, and let drivers be more useful to
people, and if there is ever enough drivers doing something, we should
move the function to a 'standard' API.
I think they do need to be clear to a user/developer that a specific
API is an extension though, and isn't reliable between different
providers, so I believe we should require two things:
* All extensions have a specific prefix. For example "ex_", would
mean, "ex_resize_node".
* In the documentation for an extension function, it should include
something like:
@warning This is a non-standard extension API, and only works
for driver X.
Thoughts?
Thanks,
Paul