From: MARK CALLAGHAN Date: June 16 2009 3:25pm Subject: Re: RFC: draft of physical structure of server code List-Archive: http://lists.mysql.com/internals/36916 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the first step? On Thu, Jun 11, 2009 at 12:41 PM, Mats Kindahl wrote: > In addition, the structure shall be such that addition of features or > bug fixes normally are isolated from each other physically, that is, > are placed in different files and/or different parts of the > systems. This will reduce the risk of merges causing inadvertent > changes to the code. What is the plan for THD? How will it be extensible? Many parts of the server need access to a session context. > High-level structure > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We envision that the system consists of a number of *packages* that > together make up the code of the system. In order to build the server, > and associated components, we have a *build frame* or *build system* > that is used to manage and, especially, build the system. > > In order to support the easy addition and removal of features, we > assume that each feature is contained in a separate package (see > below) and a minimum of changes shall be required (preferably none) to > code outside this package to introduce the feature. To support this What does this mean? Code that requires no changes elsewhere is unlikely to be used anywhere. Or does this assume the pre-existence of hooks that will invoke this code when it exists? Maybe this is a strawman argument, but I think that you may be moving the problem to the hooks. > - Can the candidate package be released independently of the rest of > =A0the server? If not, i.e., changes to this package is likely to > =A0require changes to other packages, then maybe it should not be a > =A0package. Are these separate packages: parser, optimizer, execution? If so, how will you support packages that require complex data structures for their interactions (parser <--> optimizer, optimizer <--> execution)? > > Package interfaces > ------------------ > > For each package, there is a set of interfaces into the package. Each > interface is represented physically as a header file, meaning that > each package have one or more interfaces, but potentially have header > files that are not package interfaces. =A0Note that the an interface > into a package is *all* that is in a header file, meaning that we do > not place any specific requirement on the form of the interface *in > this proposal*. I don't understand the last sentence. Can you elaborate? --=20 Mark Callaghan mdcallag@stripped