On Wed, 19 Jun 2002 09:30, Peter Donald wrote: > On Tue, 18 Jun 2002 19:11, Adam Murdoch wrote: > > > This would allow us work with a single deployer across whole runtime. > > > This deployer would then access the TypeManager/RoleRegistry from > > > TaskContext.getService() and it "feels" a lot nicer. > > > > > > Thoughts? > > > > I was thinking the same thing. Maybe ExecutionFrame would be a better > > option than TaskContext? > > I would prefer to couple onto TaskContext because thats a "stable" > interface and it is available to all tasks.
Fair enough. Should we change Executor to use TaskContext as well, then?
Without looking at the code - that could be a good idea.
Originally there was no ExecutionFrame - only a TaskContext. But I separated out the two so that the ExecutionFrame could have more container specific info attached to it. However as everything is a service now - it may not be so much of an issue.
The one sticking point being that we should not make the task writer deal with creating child instances of TaskContext as the logic is a bit hectic. So maybe we could create a service to manage the creation of child contexts. Then again that seems hacky. Not sure - what do you think?
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
