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)
Subject: Re: Solving matching problems caused by plugins
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
In-Reply-To: <4182AC7D.9070504@apache.org>
References: <41819463.8020504@apache.org> <41819763.5010503@apache.org>
	 <41819D39.3050207@apache.org> <1099017958.22790.34154.camel@ighp>
	 <41824383.7090703@apache.org> <41828B38.7030100@apache.org>
	 <4182A2F0.7040702@brondsema.net>  <4182AC7D.9070504@apache.org>
Content-Type: text/plain
Organization: 
Message-Id: <1099109862.22790.42100.camel@ighp>
Mime-Version: 1.0
Date: 30 Oct 2004 14:17:44 +1000
Content-Transfer-Encoding: 7bit

Ross Gardler wrote:
> Dave Brondsema wrote:
> > Ross Gardler wrote:
> > I think that's the right idea.  Lots of stuff can be moved to be a 
> > plugin.  For example, changes/todo.html as a plugin would make that 
> > functionality optional and so people can use those reserveds names.
> > 
> > I haven't tried yet.. does the plugin location allow for input formats 
> > and output formats?
> 
> I'm starting to think that we need a more flexible plugin system that 
> would allow insertion at different points in the generation process.
> 
> For example, IMSManifest is currently broken because of having to move 
> the plugin sitemap mount to *after* the generation of things like 
> site.xml, faq.xml etc.
> 
> Your question about input and output formats is another point, output 
> formats would need to be mounted in a different location from the input 
> formats (which is all I have worked with to date).
> 
> I was thinking of moving to a system where plugins can provide three 
> sitemaps:
> 
> preprocessing (comes before *everything* in core - such sitemaps would 
> have to be very careful to only match what they need, i.e. IMSManifest 
> would match abs-linkmap, site.xml. tabs.xml etc.)

Already the project sitemap.xmap must be careful to
only match what they need.

So where does their project sitemap fit into this?

> input formats (these would be placed where the current mount is, i.e. 
> just before the default **.xml match in forrest.xmap)

Would a project sitemap still be able to match those
if they needed to?

[snip]
> > We will also have to document a "plugin contract" of what pipeline parts 
> > will be made available and supported.  I think we have need to work 
> > through some more real examples of plugins before we fully understand 
> > their power and limitations.  Then we can best write the contract.
> 
> I agree. I will, over the coming weeks move all none core functionality 
> from core into a plugin. That should give us a fair number of use cases 
> to at least draft the contract from.
> 
> The question at the moment is where to *stop* moving stuff into plugins.

Bit-by-bit until we can understand the core sitemaps again.
If we start to duplicate functionality in each plugin, then
it will become apparent where to stop.

> I'm starting to think that Forrest core should follow the Eclipse model 
> where the isn't any real functionality in core, just a solid framework 
> onto which to build the required functionality.

That sounds sensible.

> Our releases would then become (for example)

How we do releases and what they contain is something
that we need to carefully consider. Let us first get our
plugin framework settled a bit.

> - Forrest for Software Projects (core + site.xml + HTML + PDF + JavaDoc)
> 
> - Forrest for Learning Objects (core + IMSManifest + OpenOffice + Latex 
> +PDF)
> 
> - Forrest for Technical Authors (core + site.xml + docbook + PDF)
> 
> Etc.
> 
> I may be getting a little ahead of myself though ;-)

No, i think that you are correct to look ahead.

-- 
David Crossley