perl-workflow-devel — discussion list for developers of Perl Workflow

[Perl-workflow-devel] Allowing multiple factories

[Alexander K. <ak-...@cy...>]

Hi all,

in OpenXPKI, we are currently doing funny things with having multiple
different configurations available in the system and we would like to
have multiple Workflow::Factory instances with different configuration.
Unfortunately, Workflow::Factory is singleton for now. What would you
think about adding a 'force' parameter to Workflow::Factory->new()
that would allow people to create a new (second, third, ...) instance?

The alternative of subclassing Workflow::Factory works, but is not very
elegant. The RT bug #18159 gets it correctly when saying that
subclassing Workflow::Factory is broken. Even though I can have my own
Factory class and instance, once objects are created (i.e.
Workflow::State objects), they use 'use Workflow::Factory qw( FACTORY )'
instead of my factory (instance). Changing that would probably involve
passing the factory instance to every 'new()' there is, which seems like
a lot of work. For now, we are using the ugly hack of changing the
symbol table: *Workflow::State::FACTORY = sub { return $factory } (and
so on for different classes as well). If someone has an easy solution
that solves this bug, I'd be happy to implement it as well (because
people might want to change their factory in ways different to ours
and that is a good thing) ...

Best regards,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer
        ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417

[Perl-workflow-devel] POD, Kwalitee, Perl::Critic and the universe

[Jonas B. N. <jo...@gm...>]

Hello,

I have just added the following two de facto tests to CVS

	t/02_pod.t
	t/03_pod-coverage.t

The later ones fails horribly, if anybody are interested in helping  
out with better POD coverage by documenting stuff, which is not  
documented they are more than welcome.

I am working a lot with both Kwalitee (http://cpants.perl.org/ 
index.html) and Perl::Critic for other CPAN distributions, what are  
your takes on
these tools and should we integrate tests validating these metrics -  
I do that for much of my other stuff as for Kwalitee.

Currently Workflow has quite a nice Kwalitee and this is just a  
guideline and not as important as perhaps following good best  
practices and good coding guidelines.

Has anybody given some though on coding guidelines for Workflow, not  
that we are a bigger team, should we put perltidy to use and if so,  
does anybody have special ideas on perltidy configuration?

Comments?

jonasbn

[Perl-workflow-devel] current event (was: Workflow 0.26 maintenance release)

[Alexander K. <ak-...@cy...>]

Hi Jonas & all,

On Wed, Mar 07, 2007 at 09:57:05AM +0100, Alexander Klink wrote:
> > We have a lot of things on the drawing board, one of the major ones  
> > being a change of SCM from CVS to SVN. I hope I will be able to put  
> One thing that I'll be working on soon (I guess this or next week)
> is the ability to add something to the workflow structure to see
> what a workflow is currently doing. In OpenXPKI, we have lots of
> workflows and we can see their state but we can't really know whether
> they are currently "working" (i.e. executing an action or checking a
> condition, validating something, ...). I was thinking of adding
> something to the workflow that says what is currently being done so
> that we can see something like "checking condition <name>" next to
> the workflow.
> I haven't looked at where to put it in the code yet, so I am open for
> suggestions.
Work on that is coming along quite well. Because of the structure,
it looks like I can't reach my goal of saving what condition is executed
at the moment, but at least I can say that conditions are currently
being checked for some action. Here is what I've done so far:

Index: lib/Workflow.pm
===================================================================
RCS file: /cvsroot/perl-workflow/workflow/lib/Workflow.pm,v
retrieving revision 1.32
diff -u -r1.32 Workflow.pm
--- lib/Workflow.pm	15 Dec 2006 07:59:20 -0000	1.32
+++ lib/Workflow.pm	9 Mar 2007 11:52:17 -0000
@@ -10,7 +10,7 @@
 use Workflow::Exception qw( workflow_error );
 use Workflow::Factory   qw( FACTORY );
 
-my @FIELDS = qw( id type description state last_update );
+my @FIELDS = qw( id type description state last_update current_event save_events );
 __PACKAGE__->mk_accessors( @FIELDS );
 
 $Workflow::VERSION  = sprintf("%d.%02d", q$Revision: 1.32 $ =~ /(\d+)\.(\d+)/);
@@ -70,6 +70,10 @@
     # This checks the conditions behind the scenes, so there's no
     # explicit 'check conditions' step here
 
+    if ( $self->save_events() ) {
+        $self->current_event('Checking conditions for ' . $action_name);
+        FACTORY->save_workflow( $self );
+    }
     my $action = $self->_get_action( $action_name );
 
     # Need this in case we encounter an exception after we store the
@@ -79,10 +83,20 @@
     my ( $new_state, $action_return );
 
     eval {
+        if ( $self->save_events() ) {
+            $self->current_event('Validating input for ' . $action_name);
+            FACTORY->save_workflow( $self );
+        }
         $action->validate( $self );
         $log->is_debug && $log->debug( "Action validated ok" );
+
+        if ( $self->save_events() ) {
+            $self->current_event('Executing ' . $action_name);
+            FACTORY->save_workflow( $self );
+        }
         $action_return = $action->execute( $self );
         $log->is_debug && $log->debug( "Action executed ok" );
+        $self->current_event('');
 
         $new_state = $self->_get_next_state( $action_name, $action_return );
         if ( $new_state ne NO_CHANGE_VALUE ) {
@@ -98,7 +112,7 @@
 
         FACTORY->save_workflow( $self );
         $log->is_info &&
-            $log->info( "Saved workflow with possible new state ok" );
+            $log->info( "Saved workflow with possibly new state ok" );
     };
 
     # If there's an exception, reset the state to the original one and
@@ -109,6 +123,7 @@
         $log->error( "Caught exception from action: $error; reset ",
                      "workflow to old state '$old_state'" );
         $self->state( $old_state );
+        $self->current_event('');
 
         # Don't use 'workflow_error' here since $error should already
         # be a Workflow::Exception object or subclass
@@ -209,6 +224,7 @@
 
     $self->state( $current_state );
     $self->type( $config->{type} );
+    $self->save_events( $config->{save_events} );
     $self->description( $config->{description} );
 
     # other properties go into 'param'...
@@ -920,6 +936,14 @@
 
 Date of the workflow's last update.
 
+B<current_event>
+
+If save_event is set in the workflow configuration, Workflow saves
+persists the events (checking conditions, validating input, executing
+actions). current_event is a textual description of the event that
+is happening at the moment. If nothing is happening, current_event
+returns the empty string.
+
 =head3 context (read-write, see below)
 
 A L<Workflow::Context> object associated with this workflow. This
Index: lib/Workflow/Config.pm
===================================================================
RCS file: /cvsroot/perl-workflow/workflow/lib/Workflow/Config.pm,v
retrieving revision 1.11
diff -u -r1.11 Config.pm
--- lib/Workflow/Config.pm	8 Jul 2006 20:02:33 -0000	1.11
+++ lib/Workflow/Config.pm	9 Mar 2007 11:52:17 -0000
@@ -271,6 +271,7 @@
       type        $
       description $
       persister   $
+      save_events $
       observer    \@
           sub           $
           class         $

In the OpenXPKI persister, I now persist $wf->current_event to the
database, which seems to work fine. This of course required a change
to the database schema, so I'm not exactly sure if this is the right
way to go for everybody. I've noticed that there is something called
extra_workflow_data, but this seems to go right into the context.
What do you all think, should we go for the schema change in the DBI
persister or should we try to work around it (and if so, how?)?

Regards,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer
        ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417

Re: [Perl-workflow-devel] Workflow 0.26 maintenance release, just released to CPAN

[Alexander K. <a....@cy...>]

Hi Jonas & all,

On Wed, Mar 07, 2007 at 09:39:24AM +0100, Jonas B. Nielsen wrote:
> Sorry for the silence, but I am currently busy organizing the Nordic  
> Perl Workshop, so I have not spent much time on Workflow.
Hope you'll enjoy the workshop despite the organizing ... I've been to
the German Perl Workshop two weeks ago and it was quite an interesting
event. If you are curious, I've written a bit about in on shiftordie.de.

> We have a lot of things on the drawing board, one of the major ones  
> being a change of SCM from CVS to SVN. I hope I will be able to put  
One thing that I'll be working on soon (I guess this or next week)
is the ability to add something to the workflow structure to see
what a workflow is currently doing. In OpenXPKI, we have lots of
workflows and we can see their state but we can't really know whether
they are currently "working" (i.e. executing an action or checking a
condition, validating something, ...). I was thinking of adding
something to the workflow that says what is currently being done so
that we can see something like "checking condition <name>" next to
the workflow.
I haven't looked at where to put it in the code yet, so I am open for
suggestions.

Regards,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a....@cy...
 mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de

[Perl-workflow-devel] Workflow 0.26 maintenance release, just released to CPAN

[Jonas B. N. <jo...@gm...>]

Hi All,

Sorry for the silence, but I am currently busy organizing the Nordic  
Perl Workshop, so I have not spent much time on Workflow.

We have a lot of things on the drawing board, one of the major ones  
being a change of SCM from CVS to SVN. I hope I will be able to put  
some effort into this within a near future.

I hope everybody is ok and doing well,

take care,

jonasbn

Re: [Perl-workflow-devel] Cached conditions bugfix

[Alexander K. <ak-...@cy...>]

Hi Jonas,

On Mon, Jan 29, 2007 at 03:53:09PM +0100, Jonas B. Nielsen wrote:
> Good job, please add an entry to the Changes file (top) with a brief  
Thanks.

> description of the patch - I will format the file prior to release.
Done, I've also added a brief description of the patch I've submitted
a while ago which solves a problem with an autorun error message.

> Speaking of release, just let me know when you want a new release to  
> CPAN et al.
The earlier the better I guess, but we are not really in a hurry at
the moment, so take your time if you like.

Regards,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer
        ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417

Re: [Perl-workflow-devel] Cached conditions bugfix

[Jonas B. N. <jo...@gm...>]

Hi Alexander,

Good job, please add an entry to the Changes file (top) with a brief  
description of the patch - I will format the file prior to release.

Speaking of release, just let me know when you want a new release to  
CPAN et al.

jonasbn

On 29/01/2007, at 14.50, Alexander Klink wrote:

> Hi all,
>
> I've just committed a small bugfix for the cached conditions.
> Currently, if we have a workflow that is running in a circle, i.e.
> visiting one autorun state more than once, the conditions are only
> checked once. When coming by the next time, the cached conditions
> are used, which is not what was intended (the cached conditions should
> be local to the current check of available activities). The patch
> fixes this by deleting the condition cache before checking the
> conditions.
>
> Greetings,
>     Alex
> -- 
> Dipl.-Math. Alexander Klink | IT-Security Engineer
>         ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

[Perl-workflow-devel] Cached conditions bugfix

[Alexander K. <ak-...@cy...>]

Hi all,

I've just committed a small bugfix for the cached conditions.
Currently, if we have a workflow that is running in a circle, i.e.
visiting one autorun state more than once, the conditions are only
checked once. When coming by the next time, the cached conditions
are used, which is not what was intended (the cached conditions should
be local to the current check of available activities). The patch
fixes this by deleting the condition cache before checking the
conditions.

Greetings,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer
        ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417

Re: [Perl-workflow-devel] Migrating from CVS to SVN as SCM

[Jonas B. N. <jo...@gm...>]

Ok,

So we migrate to SVN.

I am currently in the process of organizing the Nordic Perl Workshop,  
so I am quite busy when not working, but I will attempt to line up  
everything and write a simple, and then I will notify the list again  
with the plan.

Then we can set a date and execute the plan.

This might seem overly strutured, but I need this in order to  
schedule it with my other activities.

jonasbn

On 25/01/2007, at 9.55, Alexander Klink wrote:

> Hi Jonas,
>
> On Thu, Jan 25, 2007 at 09:43:31AM +0100, Martin Bartosch wrote:
>> sorry for the late answer, I was quite busy...
> same here (same project :-) ...
>
>> A friend did this on SF and as far as I remember it went smoothly and
>> without any problems. SVN has many advantages, and I would appreciate
>> to have a SVN repository instead of CVS.
> I fully agree. Atomic revisions for the whole set of files instead
> of for each file individually and the ability to use it even behind
> really restrictive firewalls are the key killer features for me.
>
> Regards,
>     Alex
> -- 
> Dipl.-Math. Alexander Klink | IT-Security Engineer
>         ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

Re: [Perl-workflow-devel] Migrating from CVS to SVN as SCM

[Alexander K. <ak-...@cy...>]

Hi Jonas,

On Thu, Jan 25, 2007 at 09:43:31AM +0100, Martin Bartosch wrote:
> sorry for the late answer, I was quite busy...
same here (same project :-) ...

> A friend did this on SF and as far as I remember it went smoothly and  
> without any problems. SVN has many advantages, and I would appreciate  
> to have a SVN repository instead of CVS.
I fully agree. Atomic revisions for the whole set of files instead
of for each file individually and the ability to use it even behind
really restrictive firewalls are the key killer features for me.

Regards,
    Alex
-- 
Dipl.-Math. Alexander Klink | IT-Security Engineer
        ak-...@cy... | working @ urn:oid:1.3.6.1.4.1.11417

Re: [Perl-workflow-devel] Migrating from CVS to SVN as SCM

[Martin B. <vc...@cy...>]

Hi Jonas,

sorry for the late answer, I was quite busy...

> So my question to you is, is it something we should persue, as far as
> I can understand from the manual
> http://sourceforge.net/docs/E09, it should be possible to migrate to
> SVN from CVS.

A friend did this on SF and as far as I remember it went smoothly and  
without any problems. SVN has many advantages, and I would appreciate  
to have a SVN repository instead of CVS.

Cheers

Martin

[Perl-workflow-devel] Migrating from CVS to SVN as SCM

[Jonas B. N. <jo...@gm...>]

Hi All,

Martin Bartosch have mentioned to me earlier, it would be nice to  
move from CVS to Subsversion.

When setting up the project at SF.net I did want to change SCM at the  
same time and the current SCM was CVS.

So my question to you is, is it something we should persue, as far as  
I can understand from the manual
http://sourceforge.net/docs/E09, it should be possible to migrate to  
SVN from CVS.

Let me know what you think,

jonasbn

Re: [Perl-workflow-devel] Workflow Context Persistence ?

[Martin B. <vc...@cy...>]

Hi,

> I played around with the Workflow module and the Ticket example some
> more and found that the context is not persistent. It is also not
> possible to create a custom context object, because the factory  
> directly
> calls Workflow::Context->new(). So I can't create my own persistent
> context object (or can I ???).

you can do this, but you will have to write your own persister. For a  
real-life example have a look at the database persister we wrote for  
the OpenXPKI project:

http://openxpki.svn.sourceforge.net/viewvc/openxpki/trunk/perl- 
modules/core/trunk/OpenXPKI/Server/Workflow/Persister/DBI.pm?view=markup

Cheers

Martin

[Perl-workflow-devel] Workflow Context Persistence ?

[Robert H. <Rob...@gm...>]

Hello,

I played around with the Workflow module and the Ticket example some 
more and found that the context is not persistent. It is also not 
possible to create a custom context object, because the factory directly 
calls Workflow::Context->new(). So I can't create my own persistent 
context object (or can I ???).

In my planned application scenario for perl Workflow module I have long 
running processes which require the cooperation of multiple teams. Example:

Shutdown Application on Server 1
Update Software on Server 1
Send schema update request to database team
Wait for approval of schema update
Start Applicatin on Server 1

Shutdown Application on Server 2
Update Software on Server 2
Send schema update request to database team
Wait for approval of schema update
Start Applicatin on Server 2

So it is possible for the workflow to be paused for a longer time and 
the program is stopped. After the database team has approved the schema 
update, the program is executed again. Now in the current 
implementation, the context is lost.

How should I make the context persistent ? Any suggestions or "design 
pattern" from users using Workflow for a longer time now ?

Regards,
Robert

Re: [Perl-workflow-devel] Retrieving all Workflows available in ?

[Robert H. <Rob...@gm...>]

Hi,

Currently I'm just reading the documentation of Workflow :) to get 
familliar with the package and to see if it is suitable for my needs 
(distributed system administration tasks). I'm planning to use SQLite 
(or some other SQL database). So it's possible to query the tables 
directly (select * from workflow). I was just wondering, it there is an 
interface available, thats not documented. I think I will query the 
tables directly altought this makes the application not capable of using 
any other persister backend then sql database. With using sqlite, I 
think this ok because sqlite is "transportable and generic" enough.

Thanks,
Robert

Jonas B. Nielsen schrieb:
> Hi Robert,
>
> What backend are you using? - Workflow can be configured with several 
> different backends.
>
> I myself use Postgresql, it would have all the workflow IDs 
> retrieveable using SQL from the table: workflow.
>
> jonasbn
>
> On 02/01/2007, at 12.32, Robert Heinzmann wrote:
>

Re: [Perl-workflow-devel] Retrieving all Workflows available in ?

[Jonas B. N. <jo...@gm...>]

Hi Robert,

What backend are you using? - Workflow can be configured with several  
different backends.

I myself use Postgresql, it would have all the workflow IDs  
retrieveable using SQL from the table: workflow.

jonasbn

On 02/01/2007, at 12.32, Robert Heinzmann wrote:

> Hello,
>
> is there a way to list all workflow id's for workflows available ? As
> seen from the example (ticket), the user must _KNOW_ the workflow  
> id of
> configured/running workflows. It the user does not know the  
> workflow id,
> the user can not result the workflow.
>
> Regards,
> Robert
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

[Perl-workflow-devel] Retrieving all Workflows available in ?

[Robert H. <Rob...@gm...>]

Hello,

is there a way to list all workflow id's for workflows available ? As 
seen from the example (ticket), the user must _KNOW_ the workflow id of 
configured/running workflows. It the user does not know the workflow id, 
the user can not result the workflow.

Regards,
Robert

[Perl-workflow-devel] Development Cycle, Roadmap and Release Process

[Jonas B. N. <jo...@gm...>]

Hello,

Before writing this stuff I though I would run it by the list for  
review. These are my thoughts on the development cycle, roadmap and  
release process for the Workflow project in general.

As stated on the homepage of the project we are running under the  
following directives:

- Extensibility
- Stability

I am lacking a third directive, but I hope it will present itself at  
some point.

The reason to have the 3 directives is a technique I learned during  
education, when getting to a cross road of sort, a dicussion which  
require conclusion or an obstacle, the directives can help make the  
right decision. The reason why I have chosen these two directives are:

1. Extensibility, Workflow is a framework, it should be extensible  
for the developer/user utilizing it so it can be used to solve the  
user/developers particular problem without having to patch the core  
modules.

2. Stability, Workflow is in production in several places and when  
Chris handed it over to me as maintainer I looked at it as already  
finished, but it still has a lot of potential for improvement etc.  
and "code is never really done" to quote a book I am reading. - but  
Workflow is actually put to use and is not a toy system, so we need  
stability in order for the project to keep afloat.

I am for the release early, release often paradigm, but this is an  
open source project and it is not the primary work for most of us, so  
we make releases when there is something to release, so in order to  
keep releases frequent (and the project alive) we keep releases small.

As for development and releases, I divide this into two parts:

1. Bug/Documentation fixes, resulting in maintenance releases
2. New features or feature enhancements resulting in regular releases

The regular releases will be planned, not scheduled, but planned - in  
that sense they come from the ROADMAP and can be identified as tasks  
in the sf.net project system.

The ROADMAP is an outline of where we want to go, only the firstmost  
topic is being worked for the forthcoming release, but we can  
reprioritize, parallelize etc. as long as we have the resources and  
the will to do so.

A developer (or several) will be assigned to the ROADMAP scheduled  
activities (tasks) and it is released when it is done, until the  
release several maintenance releases might be made (based on branches  
from the last release point).

I am very much interested in development is also focused on unit- 
tests, since the release process is dependent on the test suite  
passing prior to release, but it is expected that developers does not  
break the test-suite with out notificed the rest of the project  
members. I regard the test-suite as a safeguard to keep stability,  
however tests contain bugs aswell or as in our case is not covering  
the code completely.

This brings me to the other part of the development efforts aimed at  
Quality Assurance.

I attempted to get the coverage for the project improved, this is an  
ongoing process, but the goal is stability, so we can develop more  
freely, using the test-suite as a tool to ensure we have no unforseen  
problems. We want to break tests in that sense we want the code to  
evolve, but we want to KNOW when we break it so we can address this.

The current ROADMAP looks like the following:

Development:

- Implement dynamically loading of workflows
- Implement versioning of workflows
...There are several feature requests in the system and there is not  
need for me to list them here...

QA:

- Improve test coverage

So that was sort of what I have in mind and things are up for  
discussion, I will get back with a preliminary draft of my ideas on  
how the bug handling process.

Looking forward to hearing your thoughts on the topic,

jonasbn

[Perl-workflow-devel] Teaming-up... Martin Bartosch

[Jonas B. N. <jo...@gm...>]

Hello,

I am glad to announce that Marting Bartosch has joined the team as  
developer.

Martin is a also patcher of Workflow in the past and is  working with  
Workflow professionally and he has things on the drawingboard that  
will take Workflow to a new and higher level.

I am happy to get patchers who have an interest in the life and  
development of Workflow involved in the project, since we can then  
work more closely together in getting the software shipped in the  
right direction and open discussion and development will be more  
beneficial to us all.

Anyway I am happy to have Martin onboard and I am sure we can say  
that it looks like Workflow will really take off in 2007.

jonasbn

Re: [Perl-workflow-devel] Teaming up... Alexander Klink

[Alexander K. <ak-...@cy...>]

Hi Jonas,
Hi all,

> I am glad to announce that Alexander Klink has joined the team as
> developer.
Thanks, I'm happy to join.

> Alexander is working with Workflow professionally and his
> contributions has been (and will be) a benefit to the project in
> general.
To be a bit more specific here, I am one of the core developers of
the OpenXPKI project (see www.openxpki.org), which is developing
a professional trust center/certificate authority software. Workflows
are one of the core concepts of OpenXPKI and thus Workflow is one of
the most important modules we use.
Here is a bit of a wishlist from us, if no-one speaks up, we will
probably implement those features in the future:

- fetching a workflow ID only: today you still have to pass the ID
  and the type of the workflow to fetch_workflow(), which is a bit
  annoying and pretty useless
- Workflow versioning: As we might want to change workflow definitions
  while our software is running, we want to introduce versions for
  the definitions. This means that existing workflows could
  continue running with the old configuration, while new workflows
  of the same type can already use the new configuration.
  This is something that Martin Bartosch is considering to implement.
- Workflow activity state: It would be pretty useful for us to know
  whether a workflow is currently doing something (e.g. executing
  an activity or checking a condition). This is something that
  could possibly be implemented using a flag that is set just before
  checking a condition or running an activity and unsetting it
  afterwards. This would for example enable us to "restart"
  autorunning workflows that have stopped in a state that has the
  new "may_stop" flag.

I have also added those to the SF feature request tracker.

Furthermore, I still have a little script lying around that visualizes
Workflow definitions using GraphViz. This is particularly useful if you
have large Workflows that you have designed on paper and you want to
check whether your XML definition matches your plan. For a preview of how
this looks like see:
http://events.ccc.de/congress/2006/Fahrplan/attachments/1113-OpenXPKI_23C=
3_Paper.pdf
(page 2)

Once I clean it up a little, I could check it in as well (where would be =
a
good place for it?).

> There is plenty of room for more developers and contributors.
I guess at least Martin will be on board soon :-)

Greetings,
    Alex

[Perl-workflow-devel] Teaming up... Alexander Klink

[Jonas B. N. <jo...@gm...>]

Hello,

I am glad to announce that Alexander Klink has joined the team as  
developer.

Alexander is the person behind several patches improving Workflow in  
general.

Alexander is working with Workflow professionally and his  
contributions has been (and will be) a benefit to the project in  
general.

I am particular excited with Alexander's involvement and I have high  
expectations to the future of the project, so Alexanders  
participation is a clear strengthening of the project team, which is  
loosely based on patchers, a distributor (porter) and me.

There is plenty of room for more developers and contributors.

jonasbn

[Perl-workflow-devel] First shot at webpage uploaded

[Jonas B. N. <jo...@gm...>]

Hello,

I have uploaded a first attempt at a project website.

	http://perl-workflow.sourceforge.net/

I am using an template/design from OSWD, which looked nice, but I  
think we need a more catchy or at least workflowish logo.

I am working on making a complete browsable documentation set, based  
on the documentation shipped with the distribution, but I am not  
completely satisfied with the result just yet.

I will also be writing up even more content for the pages when I get  
the time.

Feedback is welcome and if somebody is interested in driving the site  
(even making new layout/content) let me know.

jonasbn