I think the value in this case is less in the simplicity of the code, and more in the fact that it allows you to fully document the intentions/behavior of a given promise without having to resort to 3rd party code, i.e. the promise becomes self-documenting.
Paul Krizak 7171 Southwest Pkwy MS B200.3A MTS Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Global IT Infrastructure Fax: (512) 602-0468 On 09/13/10 15:21, Mike Hoskins wrote: > On 9/13/10 12:20 PM, "Paul Krizak"<paul.kri...@amd.com> wrote: >> I can see the advantage to using a persistent class in this case. It >> allows you to have different timeouts for different events. If the wget >> fails, the "I failed to wget" class can have no persistence (so the next >> 5-minute run will try again) while the "I was able to wget" class may >> have a persistence of several hours (and maybe a splayclass as well) to >> prevent hammering the target server. > > While I see the potential value of "persistent classes" -- I've always done > this in modules, which set classes based upon actions, which have whatever > "locking/retry" mechanism I chose. > _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
