Summary?

[David Blevins <da...@visi.com>]

For myself and others can someone post a real short summary of where  
this conversation is at?


-David

Re: Summary?

[Greg Wilkins <gr...@mortbay.com>]

David Blevins wrote:
> For myself and others can someone post a real short summary of where 
> this conversation is at?

For my part.....

I agree with Jules that the session API (really a state API)
and the policy API should be considered separately.

My main concern at the moment is the state API, as I would really
like to have a single SessionManager implementation for Jetty that
would be responsible for the web aspects of session management,
but would delegate via the API to an arbitrary state store (be
in clustered, persistent or whatever).

So I see there is a conflict between a KISS one-size fits all
state API and something that will support all the good, bad and
ugly behaviour that a compliant servlet container needs from
a session state store.    But Dain has convinced me that by
using a structured name space, I should be able to address most
of the issues of cross context dispatch.   He also agrees that
we could add an API for notification that would support the web 
requirements.

With that, I'm happy to go ahead and write a session manager
based on the state aspects of this API.   I'm just waiting for 
(and Jan may help with) a maven2 build and I'll start the 
jetty 6 module and give the API a try.

But I've also had some long conversations with Jules about
both the state and the policy aspects of the API.  I can see
his concerns about the structured name space approach making
it difficult to efficiently implement all clustering configurations,
but I can't see a way around that without adding a deep API that
supports multiple state stores for a single session ID.  That
is probably very web specific and would complicate other uses
of the API.     I am hoping that the non-efficient configurations
are the 1% case and not the 99% case.


With regards to the policy API - I'm not sure what I think
now.   Jules has almost convinced me for the need of a standard
invocation API... which is an API to the policy implementation.
The current API, is more something that a policy implementation
can use the manipulate state.

If we do standardize a way to invoke clustering policy, then 
I'm not sure that we need the current API aspects about location
and session movement.  If the same implementation gives you a 
state store and a policy implementation, who cares how the 
policy manipulates the state store!

But policy is less my concern that state... so I still plan
to proceed with a session manager implementation and then we
will have a play ground to experiment with policy.

cheers