* Michael Matz
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
Fully agreed.
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. */ };
Right. Maybe enhanced by some versioning data to ensure the policy implementation actually matches the policy API. And we need a couple of 'first class' object definitions like Solvable, Repo and Pool so the policy engine implementations can use them uniformly.
I.e. I would want to make the solver somehow be responsible for loading policies automagically.
Time for a '/etc/solver.conf' file or a /etc/solver/policy directory to place a .so file with the policy implementation ?
I would want the using applications to actually set them.
Well, I guess we need three layers (resp. levels) 1. Solver default policy 2. System policy 3. Application policy
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.
*g* Any pointers to a 'good', reusable plugin system ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org