forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [Proposal] Bypass PlugIns
Date Sat, 12 Nov 2005 21:15:45 GMT
Ferdinand Soethe wrote:
> Before you read on:

(I've done loads of snipping here, I'm afraid I've snipped some direct 
questions, but I want to try and stay focused on the core topic for now. 
I typed a really long reply and felt it would be one of those threads 
that went round in circles if I wasn't careful with my replies. I'm not 
ignoring your questions or assertions, just feel that they will 
resurface when we get passed this initial sticking point of me gaining 
an understanding of your needs)

> Keep in mind that there are other goals that the 'translate anything to
> everything else' when using Forrest.

I am not aware of any goals other than:

- publishing framework (not application)
- transform from various inputs to various outputs
- modular and extensible architecture
- separate presentation from content
- static or dynamic

(adapted from the info on our home page)

What are the other goals you refer to?

...

> Wrong. I am already providing a transformation to Xdoc (see input
> plugin) because it makes complete sense to re-use some of the established
> publishing pipelines (to skinned HTML, to PDF etc.).

OK, I did not understand this from your original proposal. I am now 
reading with a new understanding.

...

>>The problem with accepting plugins that do not conform to our TR is that
>>we dilute that TR and provide examples of the *wrong* way of doing 
>>things. Forrest is about multiple input formats and multiple output 
>>formats.
> 
> 
> I disagree with your interpretation of this TR. To me Forrest is about
> the option for all these things depending on a use case. It doesn't
> mean that I have to implement everything just for the sake of doing
> it.

That document is a *specification* that is "intended to be the reference 
point for developers and users in the road to making a first stable 
Apache Forrest release."

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.

That being said, the TR is an "in development" document and therefore 
open to modification where needed. Let us continue the discussion...

...

> But there are additional capabilities in SmartSlides (that I would
> consider powerful along a totally different axis) that do not work
> well with other input formats because the input simply doesn't carry
> the required information.

> For an example lets consider the ability to assign parts of the
> presentation to different speakers for co-presentations (and create
> slidy-Slides that show these in different color (to the speakers, not
> the audience!):
> 
> - There's probably no good way of adding this info to an impress
>   presentation, so your plugin would really fall back to be a simple
>   slidy plugin.

Hmmm.... XML is, by definition, and extensible language, therefore any 
XML document can (in theory) capture any information you need.

>>With your new schema we can convert from whatever input format to your
>>new schema and leverage the full power of Slidy from any input format.
> 
> 
> I agree. And I'm totally with you on doing this in one of two possible
> ways:
> 
>   1. Preferred: As one pipeline in the smartslides output-plugin
>      that translates xdocs to simple slidy presentations (in addition
>      to another one that translates the smartslides grammar directly
>      to enhanced slidy presentation that I would call smartslides.

It is this insistence on the fact that XDoc can only cope with "simple" 
slidy presentations that I want to focus on.

You state that Forrest *cannot* do what you need to do, therefore you 
want to bypass its internals.

If Forrest truly cannot provide what you need then it means one of two 
things:

a) You should build an *application* that uses Forrest when it needs it 
and doesn't when it doesn't need it (i.e. bypass the core)

or

b) We truly do have a need for your "bypass plugins"

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.

Ross

Mime
View raw message