On Thursday, June 21, 2001, at 06:54 AM, Rafal Krzewski wrote:
> Herv� Guidetti wrote:
>
>> My question is : how can I create a new windows with another session
>> id or
>> how can I tell Turbine to create a new session for the new window?
>
> Currently, you cannot do that with Turbine in an elegant way.
> You can read my summary of the problem and proposed solution at
> http://jakarta.apache.org/turbine/proposals/browser-bound-app-
> context.html
>
> Please note that his is a difficult problem, implementing my solution
> correctly
> will consume insane amounts of memory in systems with long lasting
> sessions.
Rafal,
A couple months ago Pere Torrodellas posted a reply in a thread titled
"Seperating Application Flow from actions/views" where he mentioned
having implemented a workflow framework. A workflow was defined in
XML as a set of states which could have pre-requisites and such. In
your discussion of browser-bound application context, you mention
needing essentially to store every state for every window for every
user -- hence the insane amounts of memory. I wonder if Pere's idea
of a well defined state-machine for the workflow of the web application
would reduce the number of states that have to be contained in memory
to something manageable. Perhaps with the window-session-id's you
propose along with a map of the possible states, a past state could be
reconstructed rather than restored from memory. Or use that when a
particular requested state has been dropped from the cache.
Here's a repost of Pere's original (it was sent while the archive was
not capturing the list):
> From: Pere Torrodellas [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 19, 2001 11:36 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Seperating Application Flow from actions/views
>
>
> Hi,
>
> I'm not sure if the following is relevant to your discussion, but to
> add my
> 2
> cents...
>
> Just before discovering Turbine and getting involved in our present
> test, I
> designed and developed a Workflow framework that I think follows some of
> your
> ideas. It does work in our testing environment, but has not been used
> in any
> real development yet. These are its general characteristics:
>
> - A workflow is defined in XML as a set of states.
>
> - A workflow can be applied to any Object that implements a specific
> interface.
>
> - More than one workflow can be defined and launched on an Object at the
> same
> time. The framework controls mutual pre-requisites and exclusive use of
> the
> controlled object to synchronise them.
>
> - Each workflow state has a set of actions, whose successfull completion
> leads
> to a new state. An unsuccessful action leaves the Object in the state it
> was.
> All this is defined in the XML file.
>
> - Each action can have a set of pre-requisites (states of other
> workflows,
> also
> defined in the XML file) that must be met for the action to be
> selectable
> for
> execution (f.e. "Publish Document" can not be executed before the
> "Authorisation" workflow reaches the "Is Authorised" state).
>
> - Actions can be synchronous or asynchronous.
>
> - An action can perform any process on the controlled Object. Actions
> can be
> defined to have exclusive control on the controlled Object while
> executing,
> or
> able to share control with actions of other wokflows that are running in
> parallel
>
> - Actions get input data from the requester as an object of a specific
> class,
> and report the results in the same way.
>
> - There is an interface to control permissions to launch workflows and
> execute
> actions.
>
> - Given a user, an object and a state, the framework reports what
> actions
> the
> user can request according to his/her permissions.
>
> - There's a log to register who does what and when.
>
> Seen under the Turbine light:
>
> - A Turbine Action/Screen would be the requester of the controlled
> object(s)
> state and possible actions, reporting them to the user in any suitable
> way.
>
> - A Turbine Action would request the execution of a workflow action
> selected
> by
> the user, and decide what Screen to return in function of the results.
>
> - The execution permissions would be managed with Turbine Security.
>
> - The Object state(s) would be controlled with the Turbine DB and Peers.
>
> - The framework log would be set to use Turbine Log.
>
> I'm sure that there's still a lot of work to be done on it; maybe our
> next
> project will use it with Turbine.
>
> I'm not sure of the legal status of all this, but I certainly can
> discuss
> the
> general ideas if anyone is interested.
>
> Pere Torrodellas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
