rob05c commented on issue #4534: Fix ORT atstccfg to allow using new features in the latest Traffic Ops URL: https://github.com/apache/trafficcontrol/pull/4534#issuecomment-604463506 >maybe the TO Go client should optionally downgrade the request I'd also like to add, as someone who is frequently forced to use the TO client, a frequent pain point is the opacity and hiding of information from the user, trying to do the "right thing," which ends up making it difficult or impossible for the client's user to do what needs done. This isn't a new pain point, and it isn't exclusive to version things. It's bad enough, I've _frequently_ seriously considered making my apps just use http.Client instead, because it would be easier. But the biggest example of this is the API version. You can't tell the client to request a different API version, or even find out the API version it's using. In theory, this is the "right" solution, but in practice, it often makes it extremely painful to work with. If we go with something along the lines of your suggestion, I think it would make it a lot easier to use if instead of automatically requesting different versions, we let the user decide. For example, we could have two clients, client and "traffic_ops/clientprev" which actually share all the logic code except the request functions. Or maybe the same client with e.g. GetDeliveryServices() and GetDeliveryServicesV14(), where the latter either actually returns a DeliveryServiceV14, or else a DeliveryService with any fields newer than V14 nil (the advantage of that is the symbol doesn't change, doesn't break compiles, and doesn't require updating client apps when the real symbol changes; the disadvantage is that users would have to be aware of it). Along with some kind of GetSupportedVersion(). Something along those lines. Speaking from experience, giving users control like that would be a lot easier to use, and help with a lot of the pain points of the client.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services