On Wed, Jun 04, 2014 at 05:27:44PM -0500, Dennis Gilmore wrote: > > I have a suggestion make everything provide and validate api info. > > this is something koji does, though we to date have not broken api, we > expect we will do when we start on koji-2.0 so each app would provide > a getAPIVersion() function, then the consumers validate that they know > how to talk to that API version. > > for bodhi for instance apps could check for api version if it fails > assume version 1 and then be able to support both version 1 and 2, when > we deploy live bodhi2 the clients like fedpkg update will transparently > switch over. > <nod> This would be nice. I don't think it would have helped us with the pkgdb2 update where people didn't port at all but if we gave more information it could. Ideally we'd want to see something like this: >>> data = service.requestAPIVersion([(1, 2), (2, 0)], ... 'arbitrary-identification-string') >>> print(data) [[1, 2], [1, 4]] In that example the client would be claiming compatibility with API version 1.2 or later and 2.0 or later. The server would be telling the client that it can supply something compatible with 1.2, namely 1.4. If we got clients to update their code to make requestAPIVersion() calls both the client and the server would be able to track what the other wanted and was capable of. Serverside, we could keep track of what identification strings were making requests for something other than API version 2.0 and help those people port to 2.0 before deployment. Is that sort of API too confusing (because it's attempting to track information in both directions but the person using the code really just wants information in a single direction)? -Toshio
Attachment:
pgpENtGt7tBLF.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
