> On Jan 27, 2016, at 8:46 AM, Jason Kenny <jke...@yahoo-inc.com.INVALID> wrote: > > 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.
I'm arguing that starting with moving all the code around is not the right way to make progress. Work like TS-4092 is much better. Is is well scoped, has a clear goal, can be done is a reasonable time and will give immediate benefits. One way to get started on this is to try to move the traffic_logcat and traffic_logcat out to their respective cmd subdirectories. Once you start pulling on that thread I think you will be able to make some nice improvements. During that process, as you find code that deserves to be an independent module, or could be in a better source location, that is great! > > 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.
