> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> There are a couple of details to work out, but there is no
> reason why the YinYang component can't be either freely
> shared between all threads of execution, or freely reclaimed
> by the container.
Agreed - none.
Only objection being that enforcing that programming style seems
like a headshot to Avalon usability and thus acceptance.
I also think that a PerThread (or a PerClient) handling policy is
equivalent to what you have done - with the mapping of role ->
session, you can only have one session per role per client. If this
is not the case, then what are the differences between PerThread and
your proposal?
If you try to expand this - so each client can have lookup() multiple
instances of the same role - you end up pooling the sessions.
I also think that most people will end up with all the logic in
a single object they put in the session, and just use the component
as a way of extracting that object from the session and invoke a
method on it.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
