Return-Path: X-Original-To: apmail-trafficserver-dev-archive@www.apache.org Delivered-To: apmail-trafficserver-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A7A3B18153 for ; Tue, 26 Jan 2016 21:36:02 +0000 (UTC) Received: (qmail 23826 invoked by uid 500); 26 Jan 2016 21:36:02 -0000 Delivered-To: apmail-trafficserver-dev-archive@trafficserver.apache.org Received: (qmail 23761 invoked by uid 500); 26 Jan 2016 21:36:02 -0000 Mailing-List: contact dev-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@trafficserver.apache.org Delivered-To: mailing list dev@trafficserver.apache.org Received: (qmail 23748 invoked by uid 99); 26 Jan 2016 21:36:02 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Jan 2016 21:36:02 +0000 Received: from [17.228.227.26] (unknown [17.228.227.26]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 360161A003F; Tue, 26 Jan 2016 21:36:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Proposal for how to update source code layout. From: James Peach In-Reply-To: <872470909.433136.1453835262255.JavaMail.yahoo@mail.yahoo.com> Date: Tue, 26 Jan 2016 13:36:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <532468066.28515.1453761751840.JavaMail.yahoo.ref@mail.yahoo.com> <532468066.28515.1453761751840.JavaMail.yahoo@mail.yahoo.com> <95ED521F-DA57-4170-B3EE-79951A7FE387@apache.org> <872470909.433136.1453835262255.JavaMail.yahoo@mail.yahoo.com> To: dev@trafficserver.apache.org, Alan Carroll X-Mailer: Apple Mail (2.3096.5) > On Jan 26, 2016, at 11:07 AM, Alan Carroll = wrote: >=20 > 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.=