Re: Some random gibberish

Here is a slightly different perspective ....

I have a real time visualization of the Towers of Hanoi demo running and 
would like to hook up a view of the towers as well. This would let you 
see the petri net with it's token(s) in one window and a the three 
towers with moving disks in another.

The events from the engine are put into a queue which I animate later. I 
chose this approach so as to not block the engine or consume excessive 
cpu cycles when the ui receives large numbers of events from the engine.

So the engine solves the problem in < 1 sec and it takes me minutes to 
animate what just happened in a way that a user would find useful. The 
UI could also let the user rewind or fast forward the animation. 

To keep the animation synchronized with the tower display I could use 
the ui event queue to store hanoiDiskMovedEvents. Do we need a generic 
way for any ui to tell the engine to pause? Like a  'step' command in a 
debugger?

Later

D


bob mcwhirter wrote:

>>Here's a use case I would like to support using werkflow.
>>
>>Create User
>>-----------
>>
>>Steps
>>-----
>>
>>1. Gather - Get the user login, password and email address.
>>2. Validate - Ensure that the login and password are compliant with our
>>rules.
>>    
>>
>
>For this typs of interactive thing, where you want to keep displaying
>the form until folks have entered enough of the right data, I'm thinking
>will be another layer outside of what we know as 'werkflow' at the moment.
>
>I like having werkflow be messaging-based, but that doesn't lend itself
>to interactivity with immediate feedback.  So, by having a 'portal'
>layer that builds/displays/accepts form input and then shoots off a
>message to the core, we can maintain the distinction.
>
>  
>
>>3. Store - Store the users record with an unverified flag
>>    
>>
>
>I'd call this the 1st action of the core after receiving a message.
>
>  
>
>>4. Send Confirm - Send a notification to the registered address with a
>>request for confirmation confirmation
>>    
>>
>
>2nd action.
>
>  
>
>>5. Receive Confirm - Update the unverified flag for the user
>>    
>>
>
>a <receive> to wait for response.
>
>  
>
>>6a. Send Sys Alert - Notify System admin of new user registration
>>    
>>
>
>3rd action.
>
>  
>
>>6b. Index - Add the user to the list of active users
>>    
>>
>
>4th action.
>
>  
>
>>6c. Add the user to the announcements mailing list
>>    
>>
>
>5th action.
>
>  
>
>>7. End Process
>>    
>>
>
>
>  
>
>>2.1 -- Failed Validation
>>2.1.1 Notify - Notify user of validation errors.
>>2.1.2 End process
>>
>>5.1 -- Confirm not received in 48 hours
>>    
>>
>
>Yah, I've still got to work on timeouts.
>
>  
>
>>5.1.1 Remove - Remove user record.
>>5.1.2 Send alert - Notify sys admin of fail registration
>>5.1.3 End process.
>>
>>5.2 -- Receive Confirm after 5.1.1
>>5.2.1 Notify - Notify expiration of confirmation.
>>5.2.2 End process
>>    
>>
>
>  
>
>>1 is initiated via a an http request. It would be nice be be able to
>>call the werkflow engine in a blocking mode to handle the 1,2,2.1
>>interaction
>>    
>>
>
>We could, but I'd ask you think of another layer, possibly informed
>by the engine, but separate.  ie, maybe we have a <form> syntax to
>define your abstract forms, and it presses out a struts Action or
>something to handle the validation and message generation to the
>wf core.
>
>  
>
>>5.1 is a timed event. 5.2 is probably an error (ie the associated case
>>has been completed)
>>    
>>
>
>Right, designed but not implemented.
>
>  
>
>>5 and 5.2 are initiated by email. James?
>>    
>>
>If you need a soft copy please let me know. 
>
>You can have a chunk that POPs email or acts like an SMTP server to
>receive email, process it into some other easy-to-act-upon message
>which then can flow through the MessagingManager to the core.
>
>  
>
>>enough for now. I'm thinking I want to start on a full working example
>>with web, email interaction etc. User management seems to fit the bill,
>>what do others think.
>>    
>>
>
>I think the first 'problem' to solve is the user-interactive parts.
>I am working on support for synchronous actions, but there's still
>a thread-pool involved, so it won't be a blocking call.  Maybe we
>can add some blocking semantics, but I'm still leaning towards a
>UI layer external to the core sending messages.  
>
>Thoughts?
>
>	-bob
>
>_______________________________________________
>werkflow-interest mailing list
>[email protected]
>http://lists.werken.com/mailman/listinfo/werkflow-interest
>
>  
>