Almost... > #1. User starts workflow process by performing action. Let's say User A starts workflow process, by for instance, copying a file from his/her desktop to a directory on a local/remote server (this can/will be achieved by a variety of methods/protocols).
> #2. Workflow performs tasks that may take time. Yes > #3. User should not be held up waiting for a response from the server by background workflow tasks. Yes. However, User A may never even use the Web UI. User B on the other hand may be watching the queue/progress monitor for regular updates. The web UI is intended to be a monitoring and configuration tool for the underlying workflow engine. For the most part, general users would submit files (by desktop drag-n-drop, FTP, web-form, etc...) then use the web UI to monitor progress or change the queue priority (if authorised). Administrative users would have access to web forms that configure the workflow processing activity steps and the 'hot' folders that feed the processing queue. The application is intended to support deployment on a 'headless' server where all interaction is via a web UI. I hope that makes more sense? Regards, Brett -- Brett Gullan [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
