On 05/30/2012 08:45 AM, Michael Pasternak wrote:
as about/currently/ non-version specific capabilities: should be
version specific as in new version
will be added new permits and same for the, can you remind
me what was the reasons for
making them such.
I don't know, you should ask Mark o
On 05/29/2012 06:26 PM, Geert Jansen wrote:
>
>
> On 05/29/2012 03:44 PM, Michael Pasternak wrote:
>> On 05/29/2012 04:14 PM, Geert Jansen wrote:
>>>
>>>
>>> On 05/29/2012 12:12 PM, Michael Pasternak wrote:
>>>
there is no point in using this resource programmatically, as it only
conta
On 05/29/2012 03:44 PM, Michael Pasternak wrote:
On 05/29/2012 04:14 PM, Geert Jansen wrote:
On 05/29/2012 12:12 PM, Michael Pasternak wrote:
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version and some othe
On 05/29/2012 04:14 PM, Geert Jansen wrote:
>
>
> On 05/29/2012 12:12 PM, Michael Pasternak wrote:
>
>> there is no point in using this resource programmatically, as it only
>> contains enumerations
>> available in the system for given version and some other metadata,
>>
>> i.e it used by devel
On 05/29/2012 12:12 PM, Michael Pasternak wrote:
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version and some other metadata,
i.e it used by developers during the coding and it's not real system resource.
I'm
On 05/29/2012 10:56 AM, Geert Jansen wrote:
> Hi Michael,
>
> two questions:
>
> Can you elaborate on why you think there's no backwards compatibility issues?
there is no point in using this resource programmatically, as it only contains
enumerations
available in the system for given version an
> In your proposal, are you leaving /api/capabilites in place as it is
> now? If not how to you enumerate the different versions?
Yep, the lack of discoverability was my first thought also.
Cheers,
Eoghan
___
Engine-devel mailing list
Engine-devel@ov
Hi Michael,
two questions:
Can you elaborate on why you think there's no backwards compatibility
issues?
In your proposal, are you leaving /api/capabilites in place as it is
now? If not how to you enumerate the different versions?
Regards,
Geert
On 05/24/2012 09:53 AM, Michael Pasternak w
the motivation:
===
1. current design is not restfull
2.is not consistent with the rest of api impl.
impacts:
as this resource not used programmatically, we do not expect any
backward compatibility issues
planned change is:
=
from:
http://l
