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

Re: [Perl-workflow-devel] Patch - Workflow::Condition::Nested

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

Hello All (and Scott),

I have made a developer release (1.34_2) with Scott's patches applied. It should be available on your local CPAN mirror soon.

Feedback etc. most welcome - I am working on the patches from Oliver Welter, there is a minor issue. But another developer release (1.34_3) is in the pipeline.

If everything works out Workflow 1.35 could be released within a reasonable timeframe.

Happy hacking,

jonasbn

On 25/10/2012, at 18.46, "Jonas B. Nielsen" <jo...@gm...> wrote:

> Hi Scott,
> 
> Everything seems pretty good, I will do a developer release (1.34_2) shortly with this patch so we can evaluate. All tests pass and things look promising.
> 
> jonasbn
> --
> pauseid: JONASBN
> email: jo...@cp...
> twitter: jonasbn
> blog: http://logicLAB.org/
> 
> On 17/10/2012, at 15.55, Scott Hardin <sco...@hn...> wrote:
> 
>> Hi Jonas,
>> 
>> While working on designing a new workflow for OpenXPKI, we ran into the situation where we had a confusingly large number of conditions and states all tied together in a big mess. As an example, this new workflow of ours has a variable number of approvals from multiple sources: administrators manually giving their 'OK', but also things like the correct status of the device in a database counted as an "automatic" approval. The certificate is then only issued if, for example, at least 3 of the 5 possible approvals are found.
>> 
>> What we created is the notion of "Nested" conditions. Basically, the new Workflow::Condition::Nested class can evaluate other conditions directly without having to create a complex chain of workflow states, actions and conditions.
>> 
>> In the example above, we created two of these new conditions:
>> 
>> The first condition, Workflow::Condition::GreedyOR, takes a list of condition names as parameters and does a logical OR test on the whole list. In contrast to a lazy-evaluation, though, it actually evaluates _all_ of the conditions and returns the count of true values. Again, the evaluation of these child conditions is done directly in this condition.
>> 
>> The second condition, Workflow::Condition::CheckReturn, is the condition that is actually configured to be associated with a workflow activity at a particular workflow state (the other "child" conditions are merely <condition .../> entities not directly attached to activities). This CheckReturn specifies the name of the condition using the GreedyOR class and evaluates it's return value. The result is then compared with a context value to see if the policy for the number of required approvals is met.
>> 
>> Attached is a patch that should be able to be cleanly applied with or without Oliver's patches.
>> 
>> With best regards,
>> 
>> Scott
>> 
>> 
>> 
>> <0001-Add-Workflow-Condition-Nested.patch.gz>
>> 
>> 
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
>> Perl-workflow-devel mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel
> 

Re: [Perl-workflow-devel] Patch - Workflow::Condition::Nested

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

Hi Scott,

Everything seems pretty good, I will do a developer release (1.34_2) shortly with this patch so we can evaluate. All tests pass and things look promising.

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
twitter: jonasbn
blog: http://logicLAB.org/

On 17/10/2012, at 15.55, Scott Hardin <sco...@hn...> wrote:

> Hi Jonas,
> 
> While working on designing a new workflow for OpenXPKI, we ran into the situation where we had a confusingly large number of conditions and states all tied together in a big mess. As an example, this new workflow of ours has a variable number of approvals from multiple sources: administrators manually giving their 'OK', but also things like the correct status of the device in a database counted as an "automatic" approval. The certificate is then only issued if, for example, at least 3 of the 5 possible approvals are found.
> 
> What we created is the notion of "Nested" conditions. Basically, the new Workflow::Condition::Nested class can evaluate other conditions directly without having to create a complex chain of workflow states, actions and conditions.
> 
> In the example above, we created two of these new conditions:
> 
> The first condition, Workflow::Condition::GreedyOR, takes a list of condition names as parameters and does a logical OR test on the whole list. In contrast to a lazy-evaluation, though, it actually evaluates _all_ of the conditions and returns the count of true values. Again, the evaluation of these child conditions is done directly in this condition.
> 
> The second condition, Workflow::Condition::CheckReturn, is the condition that is actually configured to be associated with a workflow activity at a particular workflow state (the other "child" conditions are merely <condition .../> entities not directly attached to activities). This CheckReturn specifies the name of the condition using the GreedyOR class and evaluates it's return value. The result is then compared with a context value to see if the policy for the number of required approvals is met.
> 
> Attached is a patch that should be able to be cleanly applied with or without Oliver's patches.
> 
> With best regards,
> 
> Scott
> 
> 
> 
> <0001-Add-Workflow-Condition-Nested.patch.gz>
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

[Perl-workflow-devel] Patch - Workflow::Condition::Nested

[Scott H. <sco...@hn...>]

Hi Jonas,

While working on designing a new workflow for OpenXPKI, we ran into the situation where we had a confusingly large number of conditions and states all tied together in a big mess. As an example, this new workflow of ours has a variable number of approvals from multiple sources: administrators manually giving their 'OK', but also things like the correct status of the device in a database counted as an "automatic" approval. The certificate is then only issued if, for example, at least 3 of the 5 possible approvals are found.

What we created is the notion of "Nested" conditions. Basically, the new Workflow::Condition::Nested class can evaluate other conditions directly without having to create a complex chain of workflow states, actions and conditions.

In the example above, we created two of these new conditions:

The first condition, Workflow::Condition::GreedyOR, takes a list of condition names as parameters and does a logical OR test on the whole list. In contrast to a lazy-evaluation, though, it actually evaluates _all_ of the conditions and returns the count of true values. Again, the evaluation of these child conditions is done directly in this condition.

The second condition, Workflow::Condition::CheckReturn, is the condition that is actually configured to be associated with a workflow activity at a particular workflow state (the other "child" conditions are merely <condition .../> entities not directly attached to activities). This CheckReturn specifies the name of the condition using the GreedyOR class and evaluates it's return value. The result is then compared with a context value to see if the policy for the number of required approvals is met.

Attached is a patch that should be able to be cleanly applied with or without Oliver's patches.

With best regards,

Scott

[Perl-workflow-devel] RFE / Patchset - Custom Workflow Class

[Oliver W. <ma...@ol...>]

Hi Jonas,

please find attached another patch that enables users to have a custom
class for their workflow objects. It extends the create_workflow and
fetch_workflow methods by an additional parameter "wf_class". It is
fully backwards compatible, as long as one did not override the
footprint of those factory methods.

Also attached is a one-liner that prevents some warnings during testing.

Oliver

-- 
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721

Re: [Perl-workflow-devel] RFE / Patchset - Multiple factories

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

Hi Oliver,

Thanks for the contribution . I will have a look at it and will get back to you.

jonasbn
--
pauseid: JONASBN
email: jo...@cp...
twitter: jonasbn
blog: http://logicLAB.org/

On 23/09/2012, at 17.51, Oliver Welter <ma...@ol...> wrote:

> Hi,
> 
> I am working for the OpenXPKI project and we are using the Workflow module for a long time. We have the need to run multiple factories in parallel and used to hack the symbol table to get this running.
> I want to get rid of that hack and have prepared a patch against Workflow 1.34_1 which is attached to this mail.
> 
> The patch replaces the "FACTORY" Superglob by an internal reference pointer to the corresponding factory. The patched code passes all tests and does not modify any external interfaces. Without a special factory, the code should not show any differences and still allows using the FACTORY glob.
> 
> To use the power of the new patch, you just need to extend the Factory class with a default constructor.
> 
> I request to include this patch into the upstream release. If you need any additional tests/docs, etc feel free to ask.
> 
> Oliver
> 
> -- 
> Protect your environment -  close windows and adopt a penguin!
> PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721
> <0001-Factory-patch.patch>------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html_______________________________________________
> Perl-workflow-devel mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-workflow-devel

[Perl-workflow-devel] RFE / Patchset - Multiple factories

[Oliver W. <ma...@ol...>]

Hi,

I am working for the OpenXPKI project and we are using the Workflow 
module for a long time. We have the need to run multiple factories in 
parallel and used to hack the symbol table to get this running.
I want to get rid of that hack and have prepared a patch against 
Workflow 1.34_1 which is attached to this mail.

The patch replaces the "FACTORY" Superglob by an internal reference 
pointer to the corresponding factory. The patched code passes all tests 
and does not modify any external interfaces. Without a special factory, 
the code should not show any differences and still allows using the 
FACTORY glob.

To use the power of the new patch, you just need to extend the Factory 
class with a default constructor.

I request to include this patch into the upstream release. If you need 
any additional tests/docs, etc feel free to ask.

Oliver

-- 
Protect your environment -  close windows and adopt a penguin!
PGP-Key: 3B2C 8095 A7DF 8BB5 2CFF  8168 CAB7 B0DD 3985 1721

Re: [Perl-workflow-devel] Using Workflow for managing home automation

[Alejandro I. <ai...@p2...>]

On Mon, Apr 16, 2012 at 4:21 PM, Sebastian Stuecker
<seb...@go...> wrote:
> Hello,
>
> let me shortly follow up on my approaches until today.
>
[...]


>
> until I am happy...
>
> A test implementation with 8 different states now works...maybe I will find
> out that I am on the wrong approach later when I design complexer systems
> but for now...I am happy :)
>

Glad to hear because I having a hard time understanding your examples.
My mention of Petri vs. EPC was because __this__ Workflow is mostly of
type EPC, or if I'm wrong please someone correct me!

This means that this particular WF is not designed to guarantee a
perfect cycle or optimized routes, etc. You may very well define dead
ends, etc. because that is the nature of this EPC design. As the doc
says it's just a bunch of states! but it's a pretty awesome WF engine
IMHO. What I love about this WF is the easiness of integration to
other code. I've configured some pretty complex stuff using this
module and still haven't found any major limitations.

Anyway, happy to hear you are using it for Automation like stuff
because I've had a similar idea for a while in my head and maybe I'll
use it for brewing some homemade beer ;-)

Cheers,

-- 
Alejandro Imass



> Regards
> Sebastian
>
>
> 2012/4/15 Alejandro Imass <ai...@p2...>
>>
>> On Sun, Apr 15, 2012 at 5:55 AM, Sebastian Stuecker
>> <seb...@go...> wrote:
>> > Hello folks,
>> >
>> > I hope it is ok to post to this list. If not, please tell me.
>> >
>> > I am trying to utilize the workflow framework that you guys have created
>> > and
>> > I am fascinated about the possibilities and the way it is so generic and
>> > configurable.
>> >
>> > However, there is one thing I am not sure if it is achievable. I have
>> > defined a workflow with a bunch of states and I use this to control a
>> > computer. This may sound weird. This "computer" can have several states:
>> > On,
>> > Off, Booting, Halting, Unknown.
>> >
>> > Now, a user requests this computer to be just on. The user does not care
>> > about the current state. The damn thing shall be on as quickly as
>> > possible.
>> >
>> > But if the computer is currently in the off state, it cannot be on
>> > directly
>> > from there. It has to move through the booting-state and only if the
>> > booting
>> > succeeds it will be on. I have actions defined how to move from off to
>> > booting ( i just have a radio controlled socket to switch it on, but it
>> > could also be wake on lan, etc.) and I have an action to move from
>> > booting
>> > to on (some tests have to perform ok).
>> >
>> > I am looking for a way of "path-finding" from the actual state to a
>> > desired
>> > state like I can do this for example with the Graph CPAN module which
>> > can
>> > find the shortest path between two nodes.
>> >
>>
>> Coming from the automation world I find your post quite interesting
>> and in that sense the state-action-state paradigm is similar somewhat
>> to ladder logic on a PLC. What I don't understand is this last bit...
>> why do you need this path-finding stuff? As I see it, you should
>> simply stick to the event-based (e.g. EDA, SEDA, EPC, etc.) model just
>> like you would if you were automating using ladder language. Going on
>> a limb, but IMHO I think you are confusing EPC-style workflows with
>> Petri-net style WF engines.
>>
>> --
>> Alejandro Imass
>>
>>
>> > Is there any way to achieve this or do you think my whole idea is crap?
>> > :)
>
>

Re: [Perl-workflow-devel] Using Workflow for managing home automation

[Sebastian S. <seb...@go...>]

Hello,

let me shortly follow up on my approaches until today.

After looking at the philosophy of petri-net approaches I decided for
myself that I currently am not convinced that this relates to my reality I
want to model. I sticked to the workflow approach. I did nit see hot the
producer/consumer approach of petri-nets can relate to my situation, where
I think i have only systems that have exactly one state at all times, if
they are correctly designd.

I inherited the workflow class and built around some functions I wanted to
have (just for the sake of experimentation, very dirty)

- path-finding capability (Dijkstra) used from the CPAN Graph module (I
iterate through all states/actions and create in parallel a graph object)
- in the context I foresee a field called "desired state" in which the user
can set the desired state of the system.
- I have states in the system which cannot be enforced by an action but can
only be reached through a null action in case a condition fails (in my
example: my PC is not ping-able any more). I skipped those transitions in
the graph so that they are not used for path finding (the system would be
stuck otherwise)
I use a little while loop to do the following:
- is the desired state equal to the current state? if yes - > i am happy.
if no:
  - check if there is a path through the graph from the current state to
the desired state. if no? damn! (should not happen by design of system). if
yes?
     - check if the next node on the found path is part of the currently
available actions. if yes?
        - do this action

until I am happy...

A test implementation with 8 different states now works...maybe I will find
out that I am on the wrong approach later when I design complexer systems
but for now...I am happy :)

Regards
Sebastian

2012/4/15 Alejandro Imass <ai...@p2...>

> On Sun, Apr 15, 2012 at 5:55 AM, Sebastian Stuecker
> <seb...@go...> wrote:
> > Hello folks,
> >
> > I hope it is ok to post to this list. If not, please tell me.
> >
> > I am trying to utilize the workflow framework that you guys have created
> and
> > I am fascinated about the possibilities and the way it is so generic and
> > configurable.
> >
> > However, there is one thing I am not sure if it is achievable. I have
> > defined a workflow with a bunch of states and I use this to control a
> > computer. This may sound weird. This "computer" can have several states:
> On,
> > Off, Booting, Halting, Unknown.
> >
> > Now, a user requests this computer to be just on. The user does not care
> > about the current state. The damn thing shall be on as quickly as
> possible.
> >
> > But if the computer is currently in the off state, it cannot be on
> directly
> > from there. It has to move through the booting-state and only if the
> booting
> > succeeds it will be on. I have actions defined how to move from off to
> > booting ( i just have a radio controlled socket to switch it on, but it
> > could also be wake on lan, etc.) and I have an action to move from
> booting
> > to on (some tests have to perform ok).
> >
> > I am looking for a way of "path-finding" from the actual state to a
> desired
> > state like I can do this for example with the Graph CPAN module which can
> > find the shortest path between two nodes.
> >
>
> Coming from the automation world I find your post quite interesting
> and in that sense the state-action-state paradigm is similar somewhat
> to ladder logic on a PLC. What I don't understand is this last bit...
> why do you need this path-finding stuff? As I see it, you should
> simply stick to the event-based (e.g. EDA, SEDA, EPC, etc.) model just
> like you would if you were automating using ladder language. Going on
> a limb, but IMHO I think you are confusing EPC-style workflows with
> Petri-net style WF engines.
>
> --
> Alejandro Imass
>
>
> > Is there any way to achieve this or do you think my whole idea is crap?
> :)
>

Re: [Perl-workflow-devel] Using Workflow for managing home automation

[Sebastian S. <seb...@go...>]

I am maybe not so good at theoratical IT therefore it might be that I am
confused and try to use this for an application where it does not fit. Why
do I think I need path-finding-stuff?

Lets say i have states a,b,c and d and actions AtoB, BtoC, CtoD and DtoA.

The "system" is in state a. Now the user decides, it shall be in state d.
>From a there is only b reachable through action AtoB. I want that the
system goes automatically to state d through more than one action without
further user input.

Application example: The user decides he wants to liste to radio music in
the living room. (User input "set LR music radio") (just a stupid example)

Now several things have to happen, assuming everything is switched off. The
PC in the living room (yes!) has to be switched on, it has to boot, the
sucessful boot needs to be detected after a certain amount of time (if
nothing goes wrong) then the "radio listening application" has to be
startet, etc. In reallity in my home it is even more complex, becuase I
need to start up the "play music stream" application on my music server,
which also might be switched off completely, etc.

So many tasks need to be completed automatically. Which ones, depends on
the state of all systems before the user input.

I am not so good in petri nets but I will look into this and maybe this is
a better model for what I want to happen in my house. Thank you for this
hint!

Re: [Perl-workflow-devel] Using Workflow for managing home automation

[Alejandro I. <ai...@p2...>]

On Sun, Apr 15, 2012 at 5:55 AM, Sebastian Stuecker
<seb...@go...> wrote:
> Hello folks,
>
> I hope it is ok to post to this list. If not, please tell me.
>
> I am trying to utilize the workflow framework that you guys have created and
> I am fascinated about the possibilities and the way it is so generic and
> configurable.
>
> However, there is one thing I am not sure if it is achievable. I have
> defined a workflow with a bunch of states and I use this to control a
> computer. This may sound weird. This "computer" can have several states: On,
> Off, Booting, Halting, Unknown.
>
> Now, a user requests this computer to be just on. The user does not care
> about the current state. The damn thing shall be on as quickly as possible.
>
> But if the computer is currently in the off state, it cannot be on directly
> from there. It has to move through the booting-state and only if the booting
> succeeds it will be on. I have actions defined how to move from off to
> booting ( i just have a radio controlled socket to switch it on, but it
> could also be wake on lan, etc.) and I have an action to move from booting
> to on (some tests have to perform ok).
>
> I am looking for a way of "path-finding" from the actual state to a desired
> state like I can do this for example with the Graph CPAN module which can
> find the shortest path between two nodes.
>

Coming from the automation world I find your post quite interesting
and in that sense the state-action-state paradigm is similar somewhat
to ladder logic on a PLC. What I don't understand is this last bit...
why do you need this path-finding stuff? As I see it, you should
simply stick to the event-based (e.g. EDA, SEDA, EPC, etc.) model just
like you would if you were automating using ladder language. Going on
a limb, but IMHO I think you are confusing EPC-style workflows with
Petri-net style WF engines.

-- 
Alejandro Imass


> Is there any way to achieve this or do you think my whole idea is crap? :)

[Perl-workflow-devel] Using Workflow for managing home automation

[Sebastian S. <seb...@go...>]

Hello folks,

I hope it is ok to post to this list. If not, please tell me.

I am trying to utilize the workflow framework that you guys have created
and I am fascinated about the possibilities and the way it is so generic
and configurable.

However, there is one thing I am not sure if it is achievable. I have
defined a workflow with a bunch of states and I use this to control a
computer. This may sound weird. This "computer" can have several states:
On, Off, Booting, Halting, Unknown.

Now, a user requests this computer to be just on. The user does not care
about the current state. The damn thing shall be on as quickly as possible.

But if the computer is currently in the off state, it cannot be on directly
from there. It has to move through the booting-state and only if the
booting succeeds it will be on. I have actions defined how to move from off
to booting ( i just have a radio controlled socket to switch it on, but it
could also be wake on lan, etc.) and I have an action to move from booting
to on (some tests have to perform ok).

I am looking for a way of "path-finding" from the actual state to a desired
state like I can do this for example with the Graph CPAN module which can
find the shortest path between two nodes.

Is there any way to achieve this or do you think my whole idea is crap? :)

Thanks for your thoughts!

Regards
Sebastian

Re: [Perl-workflow-devel] RT #52558

[Danny S. <da...@sa...>]

no pressure.
———
Danny Sadinoff
da...@sa...



On Tue, Feb 15, 2011 at 14:49, Jonas Brømsø Nielsen <jo...@gm...>wrote:

> Hi Danny,
>
> I never followed-up on this, I am sorry.
>
> I will give Worflow some attention soon. I have been buried in work since
> January and have only did a little Open Source stuff.
>
> But I will have a look at it ASAP.
>
> jonasbn
> --
> AIM: BjonasN      Gtalk: jo...@gm...
> ICQ: 62401545   MSN: jo...@io...
> twitter: jonasbn   blog: http://e-diot.dk/
>
> On 09/02/2011, at 14.49, Danny Sadinoff wrote:
>
> > Did this ever happen?   I'm all for the suggested implementation.   I'm
> still battling this bug with tactical process restarts, when a reconnect is
> really the right approach.
> >
> > you may also want to consider the approach that slashcode takes, which is
> to validate the handle before each use.
> >
> >
> http://slashcode.git.sourceforge.net/git/gitweb.cgi?p=slashcode/slashcode;a=blob;f=Slash/DB/Utility/Utility.pm;h=6acba030be7085d6e878a13326d4a4d04566471e;hb=live
> > ———
> > Danny Sadinoff
> > da...@sa...
> >
> >
> >
> > On Sat, Jan 30, 2010 at 21:34, Jonas Brømsø Nielsen <jo...@gm...>
> wrote:
> > Hello All and Danny,
> >
> > Danny asked a very interesting question, in relation to using a DBI bases
> persister and MySQL.
> >
> > He observed that the connection would go away to he wondered where one
> would code a reconnect.
> >
> > See the original ticket:
> https://rt.cpan.org/Ticket/Display.html?id=52558
> >
> > Here is my shot at a possible solution:
> >
> > The actual database connection is made in Workflow::Persister::DBI lines
> 82-89, including logging.
> >
> >    $dbh->{RaiseError} = 1;
> >    $dbh->{PrintError} = 0;
> >    $dbh->{ChopBlanks} = 1;
> >    $dbh->{AutoCommit} = $self->autocommit();
> >    $self->handle($dbh);
> >    $log->is_debug
> >        && $log->debug( "Connected to database '",
> >        $self->dsn, "' and ", "assigned to persister ok" );
> >
> > The interesting part is the association with $self, where the database
> handle $dbh is given to the getter: handle.
> >
> > We could move the database connectivity part to a separate private method
> with singleton behavior, so when accessing handle (this would be it) access
> to the database would be tested, if connectivity existing the handled would
> be returned else connection would be made or in some cases reconnected.
> >
> > I have used this pattern before and it seems to work quite nicely.
> >
> > DBI even has a ping method to check connectivity.
> >
> >        http://search.cpan.org/~timb/DBI-1.609/DBI.pm#ping
> >
> > Does anybody have reflections, objections or anything? - else I will
> initiate implementation ASAP.
> >
> > jonasbn
> > --
> > AIM: BjonasN      Gtalk: jo...@gm...
> > ICQ: 62401545   MSN: jo...@io...
> > twitter: jonasbn   blog: http://e-diot.dk/
> >
> >
>
>

Re: [Perl-workflow-devel] RT #52558

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

Hi Danny,

I never followed-up on this, I am sorry.

I will give Worflow some attention soon. I have been buried in work since January and have only did a little Open Source stuff. 

But I will have a look at it ASAP.

jonasbn
--
AIM: BjonasN      Gtalk: jo...@gm...
ICQ: 62401545   MSN: jo...@io...
twitter: jonasbn   blog: http://e-diot.dk/

On 09/02/2011, at 14.49, Danny Sadinoff wrote:

> Did this ever happen?   I'm all for the suggested implementation.   I'm still battling this bug with tactical process restarts, when a reconnect is really the right approach. 
> 
> you may also want to consider the approach that slashcode takes, which is to validate the handle before each use.
> 
> http://slashcode.git.sourceforge.net/git/gitweb.cgi?p=slashcode/slashcode;a=blob;f=Slash/DB/Utility/Utility.pm;h=6acba030be7085d6e878a13326d4a4d04566471e;hb=live
> ———
> Danny Sadinoff
> da...@sa...
> 
> 
> 
> On Sat, Jan 30, 2010 at 21:34, Jonas Brømsø Nielsen <jo...@gm...> wrote:
> Hello All and Danny,
> 
> Danny asked a very interesting question, in relation to using a DBI bases persister and MySQL.
> 
> He observed that the connection would go away to he wondered where one would code a reconnect.
> 
> See the original ticket: https://rt.cpan.org/Ticket/Display.html?id=52558
> 
> Here is my shot at a possible solution:
> 
> The actual database connection is made in Workflow::Persister::DBI lines 82-89, including logging.
> 
>    $dbh->{RaiseError} = 1;
>    $dbh->{PrintError} = 0;
>    $dbh->{ChopBlanks} = 1;
>    $dbh->{AutoCommit} = $self->autocommit();
>    $self->handle($dbh);
>    $log->is_debug
>        && $log->debug( "Connected to database '",
>        $self->dsn, "' and ", "assigned to persister ok" );
> 
> The interesting part is the association with $self, where the database handle $dbh is given to the getter: handle.
> 
> We could move the database connectivity part to a separate private method with singleton behavior, so when accessing handle (this would be it) access to the database would be tested, if connectivity existing the handled would be returned else connection would be made or in some cases reconnected.
> 
> I have used this pattern before and it seems to work quite nicely.
> 
> DBI even has a ping method to check connectivity.
> 
>        http://search.cpan.org/~timb/DBI-1.609/DBI.pm#ping
> 
> Does anybody have reflections, objections or anything? - else I will initiate implementation ASAP.
> 
> jonasbn
> --
> AIM: BjonasN      Gtalk: jo...@gm...
> ICQ: 62401545   MSN: jo...@io...
> twitter: jonasbn   blog: http://e-diot.dk/
> 
> 

Re: [Perl-workflow-devel] RT #52558

[Danny S. <da...@sa...>]

Did this ever happen?   I'm all for the suggested implementation.   I'm
still battling this bug with tactical process restarts, when a reconnect is
really the right approach.

you may also want to consider the approach that slashcode takes, which is to
validate the handle before each use.

http://slashcode.git.sourceforge.net/git/gitweb.cgi?p=slashcode/slashcode;a=blob;f=Slash/DB/Utility/Utility.pm;h=6acba030be7085d6e878a13326d4a4d04566471e;hb=live
———
Danny Sadinoff
da...@sa...



On Sat, Jan 30, 2010 at 21:34, Jonas Brømsø Nielsen <jo...@gm...>wrote:

> Hello All and Danny,
>
> Danny asked a very interesting question, in relation to using a DBI bases
> persister and MySQL.
>
> He observed that the connection would go away to he wondered where one
> would code a reconnect.
>
> See the original ticket: https://rt.cpan.org/Ticket/Display.html?id=52558
>
> Here is my shot at a possible solution:
>
> The actual database connection is made in Workflow::Persister::DBI lines
> 82-89, including logging.
>
>    $dbh->{RaiseError} = 1;
>    $dbh->{PrintError} = 0;
>    $dbh->{ChopBlanks} = 1;
>    $dbh->{AutoCommit} = $self->autocommit();
>    $self->handle($dbh);
>    $log->is_debug
>        && $log->debug( "Connected to database '",
>        $self->dsn, "' and ", "assigned to persister ok" );
>
> The interesting part is the association with $self, where the database
> handle $dbh is given to the getter: handle.
>
> We could move the database connectivity part to a separate private method
> with singleton behavior, so when accessing handle (this would be it) access
> to the database would be tested, if connectivity existing the handled would
> be returned else connection would be made or in some cases reconnected.
>
> I have used this pattern before and it seems to work quite nicely.
>
> DBI even has a ping method to check connectivity.
>
>        http://search.cpan.org/~timb/DBI-1.609/DBI.pm#ping
>
> Does anybody have reflections, objections or anything? - else I will
> initiate implementation ASAP.
>
> jonasbn
> --
> AIM: BjonasN      Gtalk: jo...@gm...
> ICQ: 62401545   MSN: jo...@io...
> twitter: jonasbn   blog: http://e-diot.dk/
>
>

Re: [Perl-workflow-devel] Moose?

[Alejandro I. <ai...@p2...>]

On Mon, Jan 31, 2011 at 4:25 PM, Kaare Rasmussen <ka...@ja...> wrote:
> Hi Alex
>
>> This way current users have a choice whether to use Standard or
>> REST-based, whoch would be a complete port/re-write. Things we do on
>
> As I understand it, backwards compatibility is a very high priority for
> Workflow. If you want to include Moose and start rewriting tings, it may be
> better to start all over with a clean slate. That includes the most difficult
> task of all: Finding a new name!! ;-)

But I see no problem in using the same Workflow namespace!

Jonas,

Would you have a problem of a RESTful branch of Workflow in the
Workflow namespace? Something like Workflow::REST ?

My rationale is that instead of forking it would be better to work
collaboratively with the existing Workflow project and community, but
use separate namespace, we could even use the same subversion repo in
a different branch.

Re: [Perl-workflow-devel] Moose?

[Kaare R. <ka...@ja...>]

Hi Alex

> This way current users have a choice whether to use Standard or
> REST-based, whoch would be a complete port/re-write. Things we do on

As I understand it, backwards compatibility is a very high priority for 
Workflow. If you want to include Moose and start rewriting tings, it may be 
better to start all over with a clean slate. That includes the most difficult 
task of all: Finding a new name!! ;-)

I'd be interested in doing a bit of brainstorming, as I may be in need for a 
sleeker Workflow engine (or just a state machine), but I think it may be off 
topic here.

-- 

Med venlig hilsen
Kaare Rasmussen, Jasonic

Jasonic                 Telefon: +45 3816 2582
Nordre Fasanvej 12
2000 Frederiksberg      Email: ka...@ja...

Re: [Perl-workflow-devel] Moose?

[Alejandro I. <ai...@p2...>]

On Mon, Jan 31, 2011 at 8:57 AM, Alejandro Imass <ai...@p2...> wrote:
> On Sun, Jan 30, 2011 at 6:52 PM, Andrew O'Brien <an...@or...> wrote:
>> Hi Alejandro,
>>
[...]
>
> Hi Andrew,
>
> I could agree on the dependencies but I don't think there would be a

[...]

> persistence onto the CPAN more easily. And finally, the WF code in
> general is aging and perhaps a good time to re-evaluate some code
> design and architectural choices as well. Maybe an HTTP/Resource based
> approach with JSON data ala CouchDB ? Could be a branch/fork as well.
>

Maybe Workflow::REST ???

This way current users have a choice whether to use Standard or
REST-based, whoch would be a complete port/re-write. Things we do on
the REST version could be ported to Standard with Mouse, or even wrap
Standard WF with MooseX::NonMoose as an intermediate step, or
something along those lines.

--
Alex

Re: [Perl-workflow-devel] Moose?

[Alejandro I. <ai...@p2...>]

On Sun, Jan 30, 2011 at 6:52 PM, Andrew O'Brien <an...@or...> wrote:
> Hi Alejandro,
>
>>
>> I do vote +1 however to port to Moose, though OT to this thread ;-)
>
> Why on earth would you slow down all applications that rely on Workflow, not to mention adding the dependencies, like this?
>

Hi Andrew,

I could agree on the dependencies but I don't think there would be a
performance penalty at all, or only marginal at best, and it's mostly
a compile-time issue. Workflow engines should be long running
instances anyway with a per-request light-weight object factory, much
like the current code, so I don't think this would really be an issue,
IMHO.

Workflow's code is meant to be extended and there are many things that
would benefit from a more formal object protocol. For example the WF
fields could greatly benefit from a type system (Int, Num, Str, etc.),
roles, etc. It would also point the code towards Perl 6.

> If there is a refactoring in the works

No, there is no refactoring in the works AFAIK. It was just a thought,
to make the WF code easier to extend and maintain.

>then perhaps look at whatever compatible module du jour (Mouse? Or was there another newer one?) that provides the most >common features without 90% of the bloat.
>

Don't get biased by sparse comments here and there around Moose. It's
true that Moose is a heavy-weight complete object system but people
that are creating this FUD around Moose fail to mention namespace
autocleaning, non-mutability and other best practicesto keep the final
code running lean. There is a factual penalty on compile time,
however, and even so, in complex code it's really not that noticeable.

A perfect example is Catalyst which was ported to Moose a while back
and I have not personally seen any performance penalty, and we do heck
of a lot of development in Catalyst. Even for development, the compile
time for re-starting a Catalyst app before or after Moose didn't
really change that much, and definitively we haven't seen _any_
performance penalties in run-time.

On the contrary, the Cat Moose code allows for more easy creation and
maintenance of the Model layer, so you can more easily design the
model classes as long-running "instances" that create light-weight
per-request objects. And supposing there is in fact a marginal
run-time performance penalty, I think the extensibility and
maintainability would greatly out-weight it, again IMHO.

In any case, it wouldn't affect current users of WF except for the
fact that they could more easily extend and maintain their adaptations
of, and help in the publications of extensions like Context
persistence onto the CPAN more easily. And finally, the WF code in
general is aging and perhaps a good time to re-evaluate some code
design and architectural choices as well. Maybe an HTTP/Resource based
approach with JSON data ala CouchDB ? Could be a branch/fork as well.

--
Alejandro

> Just a thought.
>
> Cheers,
>
> Andrew
>
>
>

Re: [Perl-workflow-devel] Moose?

[Andrew O'B. <an...@or...>]

Hi Alejandro,

> 
> I do vote +1 however to port to Moose, though OT to this thread ;-)

Why on earth would you slow down all applications that rely on Workflow, not to mention adding the dependencies, like this?

If there is a refactoring in the works then perhaps look at whatever compatible module du jour (Mouse? Or was there another newer one?) that provides the most common features without 90% of the bloat.

Just a thought.

Cheers,

Andrew

Re: [Perl-workflow-devel] Patch from Heiko (RT #64940)

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

Hi Jonas,

> We have received a patch from Heiko Schlitterman
> 
> Please see RT queue: https://rt.cpan.org/Ticket/Display.html?id=64940
> 
> The issue being fixed is longevity of workflow context.
> 
> The documentation does not say anything and it seems the context is more a scratchpad. At the same time I think Heiko's take is pretty okay - but I do not want to break anything.

as you might remember I am working for the OpenXPKI project which is using Workflow as a central primitive which forms the glue for all the PKI related components.

Back in 2006 or so I wrote an OpenXPKI specific persister for Workflow which is used instead of the original one. This custom persister does exactly what Heiko mentions: it makes sure that all Workflow context data is persisted to the database. Back then I noticed this was not the case and figured I was supposed to do it myself - what good is a workflow that loses information when persisted?

So we are definitely relying on persistent workflow context entries. For scratch data we have introduced the notion of "volatile" context entries. In our case, if the context key name starts with an underscore the persister will not write the value to database. This allows us to safely transport sensitive data between workflow activities (knowing they will not get persisted). Our policy is that an activity must not expect a required volatile input context value to exist (it might just have been resurrected by the factory). Instead, it must be prepared to compute the value itself if it is not present.

Basically, if you wish to change the behavior to what Heiko suggested, we agree that this is useful. And since we have our own persister, this change will not affect us at all.

HTH,

Martin

Re: [Perl-workflow-devel] Patch from Heiko (RT #64940)

[Alejandro I. <ai...@p2...>]

On Sat, Jan 29, 2011 at 11:39 AM, Jonas B. Nielsen <jo...@gm...> wrote:
> Hello All,
>
> We have received a patch from Heiko Schlitterman
>
> Please see RT queue: https://rt.cpan.org/Ticket/Display.html?id=64940
>
> The issue being fixed is longevity of workflow context.
>
> The documentation does not say anything and it seems the context is more a scratchpad. At the same time I think Heiko's take is pretty okay - but I do not want to break anything.
>
> Please let me know what you think,
>

It seems good but I agree with you: Context is a meant as a disposable
stash akin to TT's stash, catalysts's stash, etc. if you need to save
stuff from the context, that is _precisely_ what the ExtraData
extension is for, so no need to add this to the core IMHO.

I do understand their need however, because I do a similar thing in
p2ee. We save some of the stuff from the context in our workflows as
"state_data" is a JSON string using the standard extension mechanisms
already provided by Workflow.pm namely
Workflow::Persister::DBI::ExtraData, here is our persister config:

<persisters>
   <persister name="Inventory"
    class="Workflow::Persister::DBI::ExtraData"
    dsn="DBI:Pg:dbname=p2ee"
    user="inventory"
    password="inventory"
    date_format="%Y-%m-%d %H:%M"
    autocommit="1"
    workflow_table="wf"
    workflow_sequence="wf_workflow_id_seq"
    history_table="wf_history"
    history_sequence="wf_history_workflow_hist_id_seq"
    extra_table="wf_p2ee"
    extra_data_field="creator,citho,citho_since"
    />
</persisters>

So my vote is -1 on this incorporating this patch because this is
already avail in the core capabilities via ExtraData.

It would be interesting nevertheless to have an extension and standard
mechanism to give context persistence (but people are probably storing
all sorts of stuff like references into the context so I can't
envision how to make a general case). But before investing in
extensions to the current code I would rather invest efforts to port
Workflow to Moose first.

I do vote +1 however to port to Moose, though OT to this thread ;-)

Best,
Alex

[Perl-workflow-devel] Patch from Heiko (RT #64940)

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

Hello All,

We have received a patch from Heiko Schlitterman

Please see RT queue: https://rt.cpan.org/Ticket/Display.html?id=64940

The issue being fixed is longevity of workflow context.

The documentation does not say anything and it seems the context is more a scratchpad. At the same time I think Heiko's take is pretty okay - but I do not want to break anything.

Please let me know what you think,

jonasbn
--
AIM: BjonasN      Gtalk: jo...@gm...
ICQ: 62401545   MSN: jo...@io...
twitter: jonasbn   blog: http://e-diot.dk/

[Perl-workflow-devel] Hosting

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

Hello all,

I am seriously considering moving Workflow to a new project hosting site.

If we decide to move away from SourceForge, I just want to hear if people have any preferences or suggestions?

I have experiences with:

- Google Code (my own Test::Timer is hosted there)
- Atlassian Jira (can be free for Open Source projects, I have a paid solution hosting a lot of Open Source stuff: http://logiclab.jira.com/secure/Dashboard.jspa alternatively I could sponsor the hosting as part of the solution I already have)

Both use Subversion and have Wiki's and bug trackers integrated.

I know Git and Github has a lot of traction in the Perl community and Open Source community, but I am thinking more in term of general project hosting, where the SCM part is just a minor part and you can use Git/Github with Workflow today (https://github.com/gitpan/Workflow) or well I thought so, but it does not seem to have been updated...

As far as I can tell what it not offered by the solutions I list is a mailing list facility, so suggestions along these lines would also be most welcome.

Suggestions and discussion most welcome,

jonasbn

Re: [Perl-workflow-devel] Problem running workflow example (MyApp::Condition::CanAnnotate)

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

Hi Thomas, 

Since I am doing yet another presentation on Workflow on the 30. of November here in Copenhagen, it was my goal to get started on my documentation brush up and that would include going over the samples.

jonasbn
--
AIM: BjonasN      Gtalk: jo...@gm...
ICQ: 62401545   MSN: jo...@io...
twitter: jonasbn   blog: http://e-diot.dk/

On 21/11/2010, at 18.14, Thomas Elsgaard wrote:

> 
> Hi Thomas,
> 
> One could argue that the sample should work out of the box. I am sorry that it does not. I will investigate and have a look if we can improve the sample.
> 
> Please let us know if you experience other issues or run into problems.
> 
> jonasbn
> 
> Hi Jonas
> 
> yeah after reading a little more on the description of workflow, i realized why i got the problem, i just assumed that i could fire up under the example code, and then discover the world of workflow ;-) So yes an working example would be good, especially  for us newbies.
> 
> Thomas
> --

Re: [Perl-workflow-devel] Problem running workflow example (MyApp::Condition::CanAnnotate)

[Thomas E. <tho...@gm...>]

> Hi Thomas,
>
> One could argue that the sample should work out of the box. I am sorry that
> it does not. I will investigate and have a look if we can improve the
> sample.
>
> Please let us know if you experience other issues or run into problems.
>
> jonasbn
>

Hi Jonas

yeah after reading a little more on the description of workflow, i realized
why i got the problem, i just assumed that i could fire up under the example
code, and then discover the world of workflow ;-) So yes an working example
would be good, especially  for us newbies.

Thomas

> --