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
