Re: [Openinteract-dev] About Setup tasks

[Chris W. <chr...@gm...>]

On 12/22/05, ant...@he...
<ant...@he...> wrote:
> I noticed that most of our SPOPS configurations look pretty much the
> same (or follow the same pattern).
>
> It would be nice to be able to set some default values or generation
> rules for all of the SPOPS classes in one project - at least our spops
> configuration entries could in most cases drop from the current:
> ...
> The easiest way to do this would be to modify
> OI2::Setup::ReadSPOPSConfig but currently there is no way to extend or
> replace that piece of code. This reminds me of the problems with
> ActionResolvers, since the problem stems from the discovery of "all
> applicable factories".
>
> To me it seems that using an automatic find mechanism to determine which
> classes should be used for setup / action resolving is causing problems
> and I propose that the find mechanism would be replaced with a list of
> modules in a configuration file (probably server.ini).
>
> This way one could replace ReadSPOPSConfig with a custom one so that it
> would still qualify for other tasks that depend on 'read spops config'.

This is an interesting idea, and one of the benefits of abstracting
the dependencies to names ('read spops config') instead of classes.

I think we could probably do something like:

a) keep the autodiscovery (this is very useful)
b) allow you to specify in the server.ini that certain setup classes
should NOT be used, even though they're discovered

You could then create your own class to implement similar
functionality, return 'read spops config' from get_name() and allow it
to be discovered as normal. When we assemble the setup actions we'd
first check the server config to see what we should remove and get rid
of those.

> Even if there would be a way to make this SPOPS default configuration
> using some global configuration file and specialized syntax for
> generation rules (which I'm sure there would), I think it is very
> important that changes like these are made possible.

Sure, I agree. We might as well make EVERYTHING configurable :-)

Chris