not implemented yet
not implemented yet by the operation
not implemented yet
not implemented yet by the operation
resource solver should be using a move command rather than direct move
Optimize the solver method as follows for the common case of infinite buying capability (ie no max quantity + min time):
The flow quantity is handled at the wrong place. It needs to be handled by the operation, since flows can exist on multiple suboperations with different quantities. The buffer solve can't handle this, because it only calls the solve() for the producing operation... Are there some situations where the operation solver doesn't know enough on the buffer behavior???
moving routing opplan doesn't recheck for feasibility of steps...
endelement function should be shared with setattro function. Unifies the python and xml worlds: shared code base to update objects! (Code for extracting info is still python specific, and writeElement is also xml-specific) xml->prevObject = python->cast value to a different type
object creator should be common with the XML reader, which uses the registered factory method. Also supports add/add_change/remove. Tricky: flow/load which use an additional validate() method