RE: [FR-devel] Plugin dependencies proposal

[Rich Kilmer]

Right...two phase is what we have...actually we expose like nine phases
right now but I am reducing that to two (loaded and running).  You will
be able to add dependencies on plugins you need loaded prior to your
'load' method being called and the same for the 'start' method.  I
exposed more transitions than needed, I think, and the two should be
sufficient.  I also need to resolve circular dependencies prior to
startup like:

a depends on: b
b depends on: c
c depends on: a

And whatnot.  Time to break out the graph theory books ;-)

-rich

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On Behalf Of Philipp Meier
> Sent: Wednesday, November 06, 2002 2:06 PM
> To: address@hidden
> Subject: RE: [FR-devel] Plugin dependencies proposal
> 
> 
> Am Mit, 2002-11-06 um 18.37 schrieb Curt Hibbs:
> > Rich Kilmer wrote:
> 
> > Can you think of a legitimate case where this would be 
> insufficient? 
> > If not, then we could simply say that my plugin is 
> dependent on a list 
> > of other plugins.
> > 
> > BTW, How does Eclipse do this?
> > 
> > > This enables a "depends on" relationship but removes the kind of 
> > > infinite flexibility on event-based state transitions 
> which in the 
> > > current system can lead to some darned weird behavior.
> > >
> > > My question is this:  Is "depends on" (from UNLOADED->LOAD and
> > > LOADED->START and their reverse) sufficient?
> > 
> > It seems sufficient to me.
> 
> Not having detail knowledge of the current plugins, it seems 
> possible to me that two plugins depend on each other. This 
> generally make some kind of two-phase loading necessary. In 
> the first phase (LOADED) the plugins can be sure the other 
> one _exists_ and can make the transition to STARTED before 
> acutally _using_ the plugin.
> 
> My $0.02,
>       -billy.
> 
> -- 
> Meisterbohne       Söflinger Straße 100          Tel: 
> +49-731-399 499-0
>    eLösungen       89077 Ulm                     Fax: 
> +49-731-399 499-9
> 
> 
> _______________________________________________
> Freeride-devel mailing list
> address@hidden 
> http://mail.nongnu.org/mailman/listinfo/freeri> de-devel
> 
>