forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <ferdin...@apache.org>
Subject Re: [Proposal] Bypass PlugIns
Date Sat, 12 Nov 2005 22:37:35 GMT






Ross Gardler wrote:

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

Well, you mentioned a whole number already. And many of them such as
the publishing framework will not always require a 'translate anything to
everything else'.

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

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.

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

I disagree because it is rather hard to extend Impress
or Powerpoint to be able to add the required extra information without
hacks. How for example would you add chapters to an impress
presentation or place conditionally visible didactic info within the
content of a slide?

Almost the same with xdocs. The grammar simply does not have elements for all
the required information and using class and id-attributes to give
normal elements a special meaning is close to a hack and hard to use.

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

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.

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.

But since I expect very few or no other source to provide the
information that I need I see no point in going though this exchange
layer.

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

Well, I already have the application in the form of these
transformations. I just wanted to make it also available as a plugin for
Forrest.

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

Please reread my previous mails where I gave several examples of info
that can not usually be extracted from the normal Forrest input
formats.

And my point really is NOT about Forrest not being able to handle it,
my point is about not seeing other input formats for SmartSlides (that
provide sufficient info) and not wanting to waste resources just for
theoretical option that one day there would be.

And frankly - implementing it in xdocs to me seems like a waste of
resources.


Regards,
Ferdinand Soethe






--
Ferdinand Soethe


Mime
View raw message