Return-Path: Delivered-To: apmail-incubator-jspwiki-dev-archive@locus.apache.org Received: (qmail 31342 invoked from network); 23 Jun 2008 17:58:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jun 2008 17:58:13 -0000 Received: (qmail 73748 invoked by uid 500); 23 Jun 2008 17:58:15 -0000 Delivered-To: apmail-incubator-jspwiki-dev-archive@incubator.apache.org Received: (qmail 73733 invoked by uid 500); 23 Jun 2008 17:58:15 -0000 Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jspwiki-dev@incubator.apache.org Delivered-To: mailing list jspwiki-dev@incubator.apache.org Received: (qmail 73722 invoked by uid 99); 23 Jun 2008 17:58:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jun 2008 10:58:15 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of terry@net-frame.com designates 65.212.180.92 as permitted sender) Received: from [65.212.180.92] (HELO pyramid-03.kattare.com) (65.212.180.92) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jun 2008 17:57:24 +0000 Received: from [192.168.1.101] (ip72-192-223-99.dc.dc.cox.net [72.192.223.99]) (authenticated bits=0) by pyramid-03.kattare.com (8.13.8/8.13.6) with ESMTP id m5NHvQDQ021288 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2008 10:57:27 -0700 Subject: Re: Workflow persistence: your thoughts please.. From: Terry Steichen To: jspwiki-dev@incubator.apache.org In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-i4aPb7oaJ/Q9ygzk74wE" Date: Mon, 23 Jun 2008 13:49:57 -0400 Message-Id: <1214243397.6196.25.camel@netframe> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Checked: Checked by ClamAV on apache.org --=-i4aPb7oaJ/Q9ygzk74wE Content-Type: text/plain Content-Transfer-Encoding: 7bit I think it would help a LOT if we could provide practical examples of how workflows create unique benefits. (And maybe pull the explanations out of the javadocs and put it into a regular documentation form.) Just to show my ignorance in its full glory, in general, if I need a stateful process, I will try to capture the steps in a JSP which handles all the decision and processing logic within itself. Presumably the workflow capability provides a way to do this without the need for a dedicated JSP (using my example). But, like Harry, I've never used this capability so don't know if it would be of any benefit or not. (Like Florian, however, I presumed that the workflows were persistent - not sure what value they'd have if they had to be created from scratch all the time.) I also think this might provide an example for us to rethink what we're doing with JSPWiki. I see from the subsequent posting that JSPWiki uses workflows in two places (and I had thought it was also involved in login?). That limited role suggests that workflow functionality may be quite far removed from core JSPWiki functionality. And there's something to be said for keeping such capabilities out of the core. Knowing Andrew's capabilities, I feel certain that the workflow implementation is probably quite elegant. However, at this point I don't feel strongly about the usefulness of the workflow capability (largely because I don't know much about it). And, I think it does provide an example for considering just how far to expand JSPWiki, in what directions. Terry PS: It would be helpful if any list members who actually use the workflow functionality (particularly in a production environment) could comment about their use of it. Also, maybe Andrew could comment on any larger plans he has for moving it into a more central role in JSPWiki? --=-i4aPb7oaJ/Q9ygzk74wE--