> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > 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.
>
> What do you mean usability/acceptance? I don't see it that
> way. Could you expound?
A lot of put() and get(). I mean, just having people implement
a Component interface was too much. Making them comply with this...
> > 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?
>
> There is a difference in a PerThread vs. a PerClient handling
> policy. There can be more clients than threads. The Session
> is associated with each client.
Got it.
> > If you try to expand this - so each client can have
> lookup() multiple
> > instances of the same role - you end up pooling the sessions.
>
> That is a different problem altogether. The session is
> associated with a role. If your system requires multiple
> component instances, that is an agreement that has to be made
> between the container and the client.
Yep - and then we have either a constraint put on composers
(can't look up the same component twice), or we're back to
square one - except we're pooling sessions instead.
> > 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.
>
> Really? Is that what you do with Servlet sessions?
No.
> In either case, is that necessarily wrong?
Don't know.
It was a doom & gloom prediction. I would consider and architecture that
results in that being the easiest way out somewhat flawed. Yes, I do not
consider the servlet architecture ideal, but that's neither here nor
there.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
