trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yongming Zhao <ming....@gmail.com>
Subject Re: Proposal for how to update source code layout.
Date Wed, 27 Jan 2016 17:42:18 GMT
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 <jkenny@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 <jpeach@apache.org>
> To: dev@trafficserver.apache.org; Alan Carroll <solidwallofcode@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 <solidwallofcode@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.


Mime
View raw message