David (et al) - Comments on the StateManager. In general, I want to stress the difference between the API and the implementation.
The StateManager API doesn't use the HTTP session so that it can be be independent of it. I think an API is stronger if it is independent of other APIs, as much as possible. Now, the implementation of the StateManager could use the session. Currently it's not. We can revisit this. Yes, I am suggesting we move much of what we store in the session (User getTemp()) into StateManager. The main reason is to achieve proper scope. Information related to a user's portal page display in a browser window is not properly stored in the session, as the session is scoped for ALL browser windows from the user. (Well, there can be multiple sessions for a user depending on his cookies and browser, but there can easily be multiple windows in a session). And moving this stuff into our own API makes it cleaner than taking direct advantage of either a Turbine feature or the HTTP servlet session - from an API standpoint. So when considering the StateManager use, don't think of how it's implemented, think of the API, and the scope distinctions of the different sets of information we need to store. Then I think the advantages are clear. Of course, once we start to use this, we want the implementation to be strong enough for us! The next thing I plan to do with the implementation is tie it in with the HTTP session's timeout so that we get automatic cleanup when the session expires, using the binding interface. I'm not quite sure how this will work. If there is concern about the hashmap and thread safeness, I am happy to address these issues as well. Here are the cons David listed for us: I'll address them: > - have to duplicate a service that already exists I think this is really a statement of the implementation, as there is no API that has the same scope and the scope that we need. > - no standard life cycle events from servlet api Again, I think this is aimed at the implementation, and I want to tie in with this as just mentioned. > - can't take advantage of servlet session sharing from some > server impls If we implement by storing specialized objects in the session (known only to the StateManager implementation; Jetspeed proper would still use our StateManager API), we can take advantage of this, if desired. > - its not standard It becomes *our* standard, to fill a gap where no other standard exists. I think we will have / already have a number of API *standards* for Jetspeed like this that we will rely upon. - Glenn -------------------------------------------- Glenn R. Golden, Systems Research Programmer University of Michigan School of Information [EMAIL PROTECTED] 734-615-1419 -------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
