Well, when I originally wrote `traffic_ops_golang`, I just put everything in the `main` package, with the assumption that we'd move components as they got big enough. It seems self-evident to me that these should be packages, very little should go in `main` in any nontrivial Go app. I don't really see this as a "large structural change," these are 3 single files.
I don't think we really need to vote and approve every little Go package change. But I'm certainly not trying to circumvent the voting process, if anyone else does feel like the need to? On Wed, Nov 14, 2018 at 9:36 AM Fieck, Brennan <[email protected]> wrote: > A couple of days ago I opened a pull request to add an API response to > Traffic Ops's `/api/?$` endpoint, for the OPTIONS and GET HTTP methods. The > form and function of those changes are still works-in-progress, and > comments on them are welcome, but what I'm asking about today is more about > the challenges I faced in creating the endpoint given the way the Go > code-base for Traffic Ops is structured. > > Between Rob Butts and I, we've agreed that there are parts of the 'main' > package that ought to be made into their own package: particularly > routes.go, routing.go, routing_test.go, wrappers.go, wrappers_test.go > should ideally be in their own package(s) - possible all of it would fall > under the 'routing' package, or perhaps the wrapper code warrants its own > package. This will allow the list of endpoints and their structure to be > available to other parts of TO, as well as any client that could > potentially want that. > > With such a large structural change, I don't feel comfortable writing any > code without asking: does that sound good to everyone? > > > There are a LOT more questions that need answering before that endpoint I > made could be included, but I feel this is a good place to start. >
