List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:June 16 2009 7:26pm
Subject:Re: RFC: draft of physical structure of server code
View as plain text  
Hi Mark,

Thank you for your comments. I will try to answer your questions below.

> What is the first step?

Seeing if there are any problems with this approach of a package structure.

Once this is set, we enable a number of other worklogs (see WL#4737 for rough
list of refactoring issues).

W.r.t. the physical structure, the next steps are:

1. Fixing header files (WL#4877)

2. Providing a unified build frame (WL#4875)

3. Identifying candidate packages turn them into packages.

> On Thu, Jun 11, 2009 at 12:41 PM, Mats Kindahl<mats@stripped> 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.

This needs to be handled, yes, but that is not part of this work.

The previous approaches at fixing problems with the maintenance of the code has
failed because changes were too big and the consequences were too hard to
predict. In this case, we start with some where basic things and then proceed to
put the other pieces in place piece by piece.

We have a patch for making the THD extensible in the sense that plug-ins can add
their own session context, but there are a lot of other things to handle as well.

>> High-level structure
>> ====================
>> 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.

The package structure encourages a separation of unrelated code into different
files and, ultimately, into separate packages, but it does not mandate it.

The main problem we have had is that there is *no* separation between unrelated
changes and a single file could be changed in many ways that was or was not
compatible or related. With this structure, we at least *have* APIs between
different components,

>> - Can the candidate package be released independently of the rest of
>>  the server? If not, i.e., changes to this package is likely to
>>  require changes to other packages, then maybe it should not be a
>>  package.
> 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)?

Placing the code in different files/packages does not mean that they cannot
interoperate in the same sense that the exchange of complex data structures
between the parser and optimizer does not require them to be in the same
components/translation units/files. If they are in different files, they can
just as easily be in different packages.

Also, if functionality is closely connected, it may not make sense to separate
them into different packages.

>> 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.  Note 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?

A header file can contain declarations of variables, functions, structures,
classes, etc. From the perspective of the physical structure, this is the
interface into a package.

Best wishes,
Mats Kindahl
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
RFC: draft of physical structure of server codeMats Kindahl11 Jun
  • Re: RFC: draft of physical structure of server codeKonstantin Osipov16 Jun
    • Re: RFC: draft of physical structure of server codeMats Kindahl16 Jun
  • Re: RFC: draft of physical structure of server codeMARK CALLAGHAN16 Jun
    • Re: RFC: draft of physical structure of server codeMats Kindahl16 Jun
      • Re: RFC: draft of physical structure of server codeMARK CALLAGHAN16 Jun