List:Internals« Previous MessageNext Message »
From:MARK CALLAGHAN Date:June 16 2009 3:25pm
Subject:Re: RFC: draft of physical structure of server code
View as plain text  
What is the first step?

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.

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

> - 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)?

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

-- 
Mark Callaghan
mdcallag@stripped
Thread
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