rob05c commented on issue #3343: URL: https://github.com/apache/trafficcontrol/issues/3343#issuecomment-630888573
>TOClient.DeliveryServices.List(filters url.Value) I'm not opposed to that. Not sure if I prefer it, it feels a little strange; but that doesn't make it bad. My bigger concern is that the client is usable, and that components using it are able to work with the existing or next TO version, so they themselves can upgrade or downgrade when necessary. As long as the client is able to do what we need, I don't have a strong opinion on what it looks like. >Is that gonna jive well with the vendoring of clients in ORT? >we need to move away from self-vendoring the previous version I'm not opposed to changing the Client to support one version back, and getting rid of the need to vendor in TC itself. I don't think the usage of Go Modules will be significantly different than vendoring. Both will require not changing symbols within a major (package, not API) version. Though, the interaction with `lib/go-tc` isn't clear. People using Modules might need a translation layer to convert between major versions of `lib/go-tc`. We really probably ought to have that for vendoring, too. The `lib/go-tc` interaction is what makes this all a pain. There's no good way to handle libraries-that-use-libraries. And that's not our project's fault, it's not even Go's fault, it's a fundamental logical problem of package dependencies in apps that need to share structures. Which is why I think I agree, just directly supporting one major (TC project, not API) version back in the TO Client, so everyone using it can automatically talk to both the existing and upcoming TO (and therefore upgrade or downgrade), is probably the easiest way. There are several ways to do it. Separate libraries (`toclientv5`), client objects (`toclient.TOClientV5`), or functions on the object (`toclient.TOClient.GetServersV5`), or probably others. If we started supporting Go Modules (I think we'll need to at some point), another option might be to not do anything in the client itself, so users would use the Go Module of the prior client version to talk to that TO, and then we would add a set of translation functions to convert `lib/go-tc` structs from the prior to the latest Module. So then, users would make 2 packages themselves (because you can't use multiple versions of a module in the same package), and the older one would call the conversion functions on the objects it gets from its client, to convert them to `master` structs. Just some ideas. Again, I don't have a strong opinion what it looks like, as long as it does what users need. >I think the Go script that was written to help re-vendor the next-oldest TO Go client assumes that symbols haven't changed, meaning there might be some manual fix-up needed Yeah, that shouldn't be a big deal. The script is just a helper, we can fix it or do it manually, neither is really hard, from the ORT side. And I'm happy to help with that. ---------------------------------------------------------------- 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: [email protected]
