forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Proposal] Bypass PlugIns
Date Sun, 13 Nov 2005 10:08:32 GMT
Ferdinand Soethe wrote:

>>In other words, it is what we are working towards to get a 1.0 out. Your
>>proposal bypasses a whole chunk of that TR. Remember Forrest is a 
>>framework not an application, an application can choose to use the 
>>framework or not, but Forrest itself must stick to it's core functionality.
> Sure. But why does an optional element like a plugin have to? And why
> not allow for plugIns that allow for special applications without
> hurting anybody.

You are not proposing a single plugin you are proposing a new class of 
plugins. Each capable of enabling a whole range of functionality that is 
outside the scope of Forrests objectives (I appreciate that you disagree 
with this, but I have not understood your reasons for this and I still 
stick to my interpretation of the goals of Forrest)

The problem with this is that the Forrest Community will have to support 
any users developing that kind of plugin. We are a small community and 
we do not have the resources to support such a potentially diverse set 
of use cases. A bypass plugin, as you propose, is really a Cocoon 
application in its own right. Therefore, the Cocoon community would be 
far more suited to support that work.

Since you concede that there is no *Ntechincal reason for needing this 
type of plugin I think it is time to hear what other folk think about 
this community issue.

Perhaps the SmartSlides *mpplication* (as distinct from the slidy plugin 
and the smartslides schema) would be better suited in the tools repo, as 
an example of how to build an application with Forrest building blocks?


> I'm not saying that xdocs could not transport the info through to my
> output plugin. I'm just saying that it doesn't make too much sense
> since there won't be other inputs providing this specialized kind of
> information.

This is an unsupportable statement:

The latest versions of OOo and MS office both have the capability to 
extend their schemas.

There are other XML slide schemas that provide some of the same features 
as SmartSlides.

Your proposal will prevent us leveraging these input formats for your 
extended slidy presentations.

> And to me the whole point of a standardized middle layer like xdocs is
> to have a common exchange format in cases where input from a variety
> of sources is to be expected (and makes sense) or output to a variety
> of formats is desirable.


>>To help us understand which is the case please provide a concrete 
>>example of a SmartSlide document that Forrest cannot handle. This way we
>>can, as a community, look to see if Forrest can do what you want, and if
>>not decide whether a) or b) is the outcome of that.
> Please reread my previous mails where I gave several examples of info
> that can not usually be extracted from the normal Forrest input
> formats.

I have seen no examples. only general comments about "chapters" and 
other such concepts. I am having difficulty understanding why it cannot 
be done, efficiently, using the existing Forrest architecture.

A few years ago, with Forrest 0.5 I built the s5 plugin and created 3 
BSc, 2 MSc and 1 MBA courses with full chpaterisation, didactic notes, 
slide presentations, student notebooks etc. When you and I worked on the 
Apachecon presentation last year we enhanced the plugin to handle some 
of the features of smartslides (different speakers, speaker notes etc.)

This didn't have a specialist input schema it was marked up XDoc, but it 
worked. Why can't we leverage that? I'm looking for concrete examples, 
with code.


View raw message