Re: Some random gibberish

> 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?

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