On 01/14/2013 01:17 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
As for clearing the state, you already can't rely on that: the batch
plugin doesn't do it.
Yes, speaking of bolted on, that defines the batch plugin pretty well.
It should be fairly straightforward to clear the state between
executions though (or at least parts of it, there may be some
batch-specif cthings we'd want to maintain).
I think the problem is there are different groups of data being
maintained in the context and we don't separate them into their logical
domains. There is connection information that persists across all
commands in the batch. Then there is the per command information
specific to each command in the batch. Each should have it's own context.
But as Petr3 points out the per thread context state is kinda a junk box
where we throw in a undisciplined manner all the things we can't fit
into a best practices programming model.
Some of this is the fault of the framework design and the priorities
that drove it. But not all of this can be laid at the feet of our
framework. Some of it is due to the inflexibility of the core Python
modules we use and their poor design. A good example is the fact the
request URL is unavailable when processing a HTTP response in one of the
libraries we're using, thats just bad design and because we use that
library we have to live with it, hence sticking the request URL into the
thread local context. There are numerous example of things like this,
most are expedient workarounds to bad code design (some under our
control, some not).
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
Freeipa-devel mailing list