forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Wheller <>
Subject A question of architecture? [was] Re: [RT] How to move the skins into a plugin? Plans for leather-dev/corium
Date Mon, 01 Nov 2004 07:57:31 GMT
On Sunday 31 October 2004 19:56, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > Dave Brondsema escribió:
> >> Thorsten Scherler wrote:
> <snip/>
> >> It is also possible to have different skins for PDF output.  Why not?
> >> Or different skins for SVG output.  Or TXT output.  Just because most
> >> 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 
the architecture. Development of forrest has been on functionality and 
architecture is very flat.

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

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

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

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

- System Architecture
Covers the block-level description of the system components and how they hand 

- Quick Start
Run Forrest run.

- Tutorial
Step by Step.

- Installation Guide
Covers installation of core and components. Also covers integration between 
other systems.

- Operation Guide
Covers deployment

- Developers Guide
Covers development aspects of core and components.

- Technical Specification
Covers the technical specifications.

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

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.

Sean Wheller
Technical Author

View raw message