forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Solving matching problems caused by plugins
Date Fri, 29 Oct 2004 20:47:57 GMT
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.)

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

output formats (not sure where yet, as I haven't thought through a use 
case, I suspect Sean's Docbook plugin will be the first)

>  Is it in a location that wholesite could be in a 
> plugin?

No idea. To be honest, I've not looked since this is currently broken 
anyway.

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

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. Our releases would then 
become (for example)

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

Ross

Mime
View raw message