Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
From: Sean Wheller <sean@inwords.co.za>
Reply-To: sean@inwords.co.za
Organization: In Words
To: dev@forrest.apache.org
Subject: A question of architecture? [was] Re: [RT] How to move the skins into
 a plugin? Plans for leather-dev/corium
Date: Mon, 1 Nov 2004 09:57:31 +0200
User-Agent: KMail/1.6.2
References: <cm0th1$16k$1@sea.gmane.org> <cm190i$f3k$1@sea.gmane.org>
 <41852762.5090300@apache.org>
In-Reply-To: <41852762.5090300@apache.org>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200411010957.31563.sean@inwords.co.za>

On Sunday 31 October 2004 19:56, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > Dave Brondsema escribi=F3:
> >> Thorsten Scherler wrote:
>
> <snip/>
>
> >> It is also possible to have different skins for PDF output. =A0Why not?
> >> Or different skins for SVG output. =A0Or TXT output. =A0Just because m=
ost
> >> of our skinning is for HTML currently doesn't mean that is all we need
> >> to think about.
> >
> > Maybe we should have the pdf-plugin as subplugin of the skin-plugin.
>
> This is what made med think that plugin is probably not the right name
> for what you are proposing. It will get confusing. I would suggest we
> stick with skin for your main "controlling" "plugin" and go with
> skin-plugin for things like PDF (and all other output stage plugins).

The definition of what constitutes a plugin is blurred as are many aspects =
of=20
the architecture. Development of forrest has been on functionality and=20
architecture is very flat.

Movement to plugins broadens the role of architure and promises to make our=
=20
current understanding of forrest obsolete. We are already forced to rethink=
=2E=20
I would like to propose that we define a document called "System=20
Architecture," and develop according to that.=20

It should answer many questions and provide the common map for our=20
understanding of forrest and future consensus in development.

As a Technical Author, I would suggest that the forrest documentation set=20
include the following information set (information architecture). Some of=20
this already exists:

=2D System Description
Covers the high-level description of the systems and it's components.

=2D System Architecture
Covers the block-level description of the system components and how they ha=
nd=20
together.

=2D Quick Start
Run Forrest run.

=2D Tutorial
Step by Step.

=2D Installation Guide
Covers installation of core and components. Also covers integration between=
=20
other systems.

=2D Operation Guide
Covers deployment

=2D Developers Guide
Covers development aspects of core and components.

=2D Technical Specification
Covers the technical specifications.

Consider the following questions. The answers to which are not clear at=20
present.

Is cocoon considered a part of core?

Is cocoon just a RTE for core?

What are the primary functions of core?

Is core the glue?

Does core define the build?

Does core define the behavior of the RTE?

Is core concerned with receiving input?

What input is core concerned with?

What does core need in order to service input?

What does core do with input?

Is core concerned with presentation layer?

What does core glue together?

Will core have dependencies?

What is a plugin?

Are there different types of plugins?

Do plugins have dependencies?

Do plugins require core modification?

There may be more questions, needing answers. These just came to mind.

=2D-=20
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za