forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Re: Plugin dependencies (Was: pdf plugin config locations)
Date Fri, 22 Aug 2008 05:26:36 GMT
Den 21. aug. 2008 kl. 13.09 skrev Tim Williams:

> On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <> wrote:
>> Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler:
>>>> Is this dependency acceptable?
>>> IMO yes, since the plugin is very small and thought a infrastructure
>>> code. Like you describe the alternative to implement it in the  
>>> sitemap
>>> is cumbersome to maintain.
>> Are there other opinions? Do we need a vote before we tie ourselves  
>> to this
>> dependency?
> In the past I think we've consistently decided against having
> dependent plugins until we have a facility built in that will manage
> them properly.  I reckon this is due to version incompatibility
> problems between plugins, etc.

The dispatcher plugin is already dependent upon the  
o.a.f.p.output.inputModule, although dispatcher is in the whiteboard.  
Would this dependency stop it from being released from whiteboard?

What it looks like to me, is that the o.a.f.p.output.inputModule is  
turning into core functionality of Forrest (and necessarily so if we  
do away with skinconfig), cf the comments from Thorsten earlier in  
this thread.

Either we accept this fact, but leave the functionality as a  
(required) plugin, or we move the functionality of the  
o.a.f.p.output.inputModule into the Forrest core. Then we would have  
no dependency anymore, since core is allways there.

>>>> How should it/can it be formalised?
>>> Not sure what you mean?
>> Whether it is possible to formalize the dependency, such that if  
>> the pdf
>> plugin is specified, forrest will automatically also include other  
>> plugins
>> the pdf plugin is dependent on. But if I remember past discussions
>> correctly, this isn't possible yet.
> It is not and I believe this is the issue.  There's no way for plugin
> A to say I require version N of plugin B, for example.  Complicating
> matters, if you have two plugins with dependencies on differing
> versions of the same plugin, strange things are likely to happen.  I
> believe it's this complication (the devils in the details) that has
> kept us from having such a capability for so long.

Understandable, and I have no real solution to this.

> I'm not saying we shouldn't change the status quo but I think it's
> worthy of some discussion first.  Having said that, you seem to be on
> a good roll and I don't want long discussion to slow you down either:)


I have now done the basic work for skins-based sites, but I will have  
to do the same for dispatcher-based sites as well (otherwise the pdf  
plugin would be broken in dispatcher), which means there is still some  
time to discuss this before I commit. If we decide against the  
dependency, my changes will still work, but forwarding the user  
settings to the xsl stylesheet will be much more clumsier and hard to  

Best regards,

View raw message