* Duncan Mac-Vicar P.
Also, some documentation about how the policy mechanism is supposed to work would be nice to allow others to contribute here.
Actually, its a late night 20 minutes hack with the primary purpose to get the discussion started ;-)
Another comment: policy_exit(), what is the meaning of "exit" here?
Its just the counterpart for _init()
The policy_init() seems to allow for a "global" stuff design. Which by coincidence is the same reason why you can't use 2 ruby interpreters in the same process, because the interpreter instance is invisible, for example, what happens if 2 solver objects call policy_init()?
Two idenpendant solver objects can have two independant ruby processes, I don't see anything wrong with it.
Ho wto solve it, no idea. Only comes to my mind:
Should't the policy engine use a struct with functions, which is used by the solver, instead of allocating invisible stuff? Then every policy implementation would fill it with the right functions, and the solver could ignore them if they are null.
My thinking goes along the same lines: Have a table of policy function pointers, pointing to the default policy implementation. If a policy engine is loaded (dlopened), its _init() function replaces those pointers in the table for which the policy engine provides own implementations. Klaus -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org