Hi, On Fri, 2 Nov 2007, Klaus Kaempf wrote:
I think the policy engine could be dlopened and the ruby part should be inside bindings/ruby which is the only part of the library that depends on ruby.
Right. However, I don't have any experience with dlopen.
For better or worse, I have :-) Though I'm not sure if that's the way to go. In my mental model it would work like this: * policies are outside of solver (I think on that we all agree), solver just calls back into them from time to time * CoolApp wants to use satsolver, and also implement its own set of policies, so it will have all the code for those very policies, * CoolApp just needs a way of communicating that set of policies to the solver Hence a function "set_policy (struct policies *)" would be completely enough. Where struct policies could look similar to this: struct policies { int (*archchanges) (Solvable *a, Solvable *b); int (*allowdowngrade) (Solvable *a); /* And so on. */ }; I.e. I would want to make the solver somehow be responsible for loading policies automagically. I would want the using applications to actually set them. Let's not write yet another plugin system. I've seen too many, most of them bad; it's usually a sign that the developers don't have any other ideas anymore. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org