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? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
