Klaus Kaempf wrote:
Because it should hide the actual implementation of 'pool' or how solvables and their state are stored internally.
Remember that long-term we want zypp to be 'transaction-based', removing the need of a huge, static, in-memory, mutex-protected data structure holding global state information.
I think you are mixing to different things. Pool actually does not show any implementation detail on how solvables are stored. Actually, Pool is an abstraction on top of the sat solver pool, which has a completely different model even for statuses (job based). Pool by itself is a transaction. Pool represent the current transaction. The fact that you can't use the memento pattern to snapshot it and re-apply it does not mean we are not transaction based (and I think that would be tricky, but not impossible to implement) I think the only thing that is missing is an easier way to iterate the transaction (I will start calling the pool transaction since today, to use the new buzz) in order to do something useful with it: like: Pool.each do s if s.isToBeInstalled do foo if s.isToBeDeleted do bar end to Pool.each_to_install do s do foo end Pool.each_to_delete do s do bar end If you see, it is only syntax sugar. What the solver returns from solving is exactly a transaction, which are all statuses on the pool set by user plus the ones set by solver, so I won't start mixing models, that would only confuse people, but see where the APIs make sense to be enhanced (for example, I am not convinced on the example above, it may be cool for python/ruby which have an each construction but in c++ does not make much difference ) So, the current transaction needs always to apply to some living objects. A transaction object need to refer to a package pointer. There either you use the ids (that would make snapshoting the current pool state piececake) or you allow for more highlevel constructions like "kdelibs3", which is no longer a transaction, because if the world changes, that transaction item is no longer valid. You can use strings for jobs (input), but not for the result, because is the solver who needs to tell you exactly which one is to be installed. So a Transaction class alone, would be just a collection of pairs refering to some living object, and what to do with them, and you can get that from the pool (the API to do that could be enhanced for sure). Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org