this thread is a big evolution change in TS if it happen, glad to see the discuss right now other than change in codes. some of my points: 1, put all codes in /src/ is good idea, but move all codes into src is a very bad idea. it just don’t solve the complex, and add more complex into tracking the change history. 2, cut the complex means we should avoid more headache change for current developer and future developer, and the current make choices. 3, if you want a clean and clear code base, you need to make the code clean first, +1 to James on the dependent cleanup effort. 4, better to do more discuss and make some RFC on the short and long time plan|change.
the code change we know: 1, in Inktomi or early Yahoo age, the /mgmt/ /iocore/ bump from /proxy 2, after open sourced, we change from the static linking into dynamic linking. 3, we removed the WEBUI and many other functions, and pending to remove some more. 4, we make new features and functions to support cache<->proxy interacting. 5, some reconstruct on layout such as binaries main file moved to /cmd/ on the detail, looks like the layout problem that make everybody crazy, the problem in your case based on: 1, the layout of /mgmt/ mess in traffic_server traffic_manager the mgmt will be very complex because we need it in both server and manager, but it works not the same code base, that is the root cause of the complex. my suggestion: make mgmt a lib or iocore module and split the codes into _server and _manager _top 2, /iocore/ mess with the /proxy/ yes, this strange, but it is there. this is the problem happened in the open sourced time, maybe we should take a look of this a cut the iocore from depends on /proxy 3, some file dependents like mess. sure, we create features and we create bugs too, help find out a good fix if it bother you. so far so mess, it always hurt during the massive change, especially in the layout. but if you narrow it down, you may find the real problem and solve it, before we make the complete reconstruct in the code layout. - Yongming Zhao 赵永明 > 在 2016年1月28日，上午12:46，Jason Kenny <jke...@yahoo-inc.com.INVALID> 写道： > > 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.
