On Wed, 2012-06-20 at 12:47 +0200, Martin Kosek wrote: > 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
Given the discussion, I guess this is the best option we have right now. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel