On Wed, 2012-06-20 at 11:10 +0200, Petr Viktorin wrote:
> On 06/12/2012 02:39 PM, Petr Viktorin wrote:
> > On 06/12/2012 02:38 PM, Simo Sorce wrote:
> >> On Tue, 2012-06-12 at 13:12 +0200, Petr Viktorin wrote:
> >>> This will make older clients usable if new output items get added to
> >>> commands.
> >>>
> >>> Since there might be important information in the extra output, it's not
> >>> ignored as the ticket asks. Instead it's printed, but not formatted
> >>> nicely as the client doesn't have enough info for that.
> >>>
> >>> https://fedorahosted.org/freeipa/ticket/1721
> >>
> >> Patch is missing.
> >>
> >> Simo.
> >>
> >
> > My apologies
> >
>
>
> We decided off-list that relaxing validation is not the right thing to do.
> A better approach would be to notify the server that the client can
> accept extended data (through a header or a version parameter).
> So, ticket 1721 is invalid, but we need a better solution to make
> https://fedorahosted.org/freeipa/ticket/2732 "Provide means of
> displaying warning and informational messages on clients" possible.
>
> I think that using the existing "version" parameter (which gets added to
> RPC calls automatically) would be perfect for this.
I agree, API version is exactly what we want. We should not care about
client version or if the client is in Fedora, RHEL or Ubuntu.
>
> Simo mentioned that we don't want to make the API depend on the version
> of our client version, so other clients don't need to copy our
> versioning scheme.
>
> However, in the version argument we send the API version, not our client
> version. I think other clients should know and advertise what API
> version they are using, and the number shouldn't be specific to our client.
> It's the perfect place to learn the client's capabilities from, if we're
> okay with a linear evolution of the API (as opposed to the client
> advertising individual features).
>
> Simo, can you comment? Hopefully I didn't mishear anything on the meeting.
>
The biggest asset about API version is that we already have this number
available for clients that were already released, we don't have to
backport anything.
I would keep linear evolution of the API version number as is, but it
would be also good to assign new API capabilities with the number and
have a simple way of checking if client has the capability, i.e.
something like this:
def post_callback(self, ..., *keys, **options):
if 'warnings' in version.client_capabilities(options['version']):
send_warning('forward record added, but reverse zone not found')
continue
else:
raise errors.NonFatalError(...)
Martin
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
