I think what you are missing is that the decoupling is more complex than a few file tweaks. There is code in the wrong place. Instead of trying to move everything around in iocore,proxy,lib,mgmt and cmd, which will be only confusing when looking at different version of ATS, is to make a clean separation to something clean and simple. Honestly no one seems know what current and modern value there is in the code in mgmt, vs that of proxy, etc. We have mgmt_p dependent on proxy code compiled into traffic_server and different code in traffic_server dependent on mgmt_p. There are lots of these, and yes we could try a miniumn take on the changes. However this does not solve other issue on how we scale, manage new code, remove old in a understandable and easy way. I gave a talk on this for a reason, it is a mess. Let clean it up. You talk about these great items to clean up, however the bar of entry for many of these are higher than need to be, because of the lack of a simple, understandable layout, and the technical debt that has happen to the code in the form of dependency cycles, and items such as the I_ and P_ headers being used incorrectly, mega files that need to be broken up ( but are not because people don't know how to fix the build system), etc.... I am not saying the layout I propose is perfect, only that it is better and that it sets up a better framework for making changes in the future without massive complication people deal with now. I would like to do these improvements now as this allows use to make all those other items easier for all of us to address. I am sure other changes will happen, but those should be smaller and simpler with this work done as a base.
Jason ----- Original Message ----- From: James Peach <jpe...@apache.org> To: dev@trafficserver.apache.org; Alan Carroll <solidwallofc...@yahoo-inc.com> Sent: Tuesday, January 26, 2016 3:36 PM Subject: Re: Proposal for how to update source code layout. > On Jan 26, 2016, at 11:07 AM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > My view is that getting or at least having a target source tree that is > better organized is a big help in doing the things HRP wants to do. Certainly > when I have looked at doing that sort of cleanup, the current structure is an > impediment. For example, the RPC logic needs to be pulled out of mgmt and put > in a separate library so it can be linked easily by any executable. But where > does that go? I suppose lib/rpc but it's unclear. Sure, but we need to be really specific here in order to understand the proposal. What exactly do you mean by the "RPC logic"? Just MgmtMarshall.cc and NetworkMessage.cc? Everything NetworkMessage.cc depends on? Or do you mean the libmgmt API? > I have mixed feelings about the big shift vs. gradual. The former is more > painful but only for a short while. The latter drags out the pain so it's a > somewhat chronic condition. In either case, though, we'd need a final target > that we are working toward. If you understand how to decouple a dependency, then I think the best approach is to just decouple that dependency and move on to the next. Given a specific change, we can understand what it means and where is belongs.
