Mailinglist Archive: zypp-devel (78 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar P. <dmacvicar@xxxxxxx> [Nov 01. 2007 18:53]:
> 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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx