Fw: [Clockwork-developers] Kicking around some requirements
Status: Planning
Brought to you by:
jlouder
|
From: Charles B. H. <br...@do...> - 2001-12-21 13:08:58
|
Joel, Sorry you're receiving this twice. My SMTP server was missing the "postmaster" alias and SourceForge refused my e-mail. That should be fixed now, and I wanted to make sure this message hits the list archives. ----- Original Message ----- From: "Joel Loudermilk" <jo...@lo...> To: <clo...@li...> Sent: Thursday, December 20, 2001 9:53 PM Subject: Re: [Clockwork-developers] Kicking around some requirements > | 1) Dynamic evaluation of schedule: There should be a capability within the > | scheduler to evaluate certain values dynamically. In other words,> | definitions of jobs > | could include, say, some variable, whose value would not > | be evaluated until runtime. > Can you give an example of this? I'm having a hard time understanding this > feature. As a part of the definition of a job, it should be possible to use variables. For example, in specifying what user account should be used to run a job, it should be possible to, instead of directly specifying an actual account, specify a variable which would contain the name of the user. This variable should not be evaluated until runtime, which would allow for easier and more efficient changes to the schedule by means of manipulating the variables, rather than the definitions of the jobs themselves. One idea I had with regard to this is even allowing the variables to be evaluated on each client if desired, rather than on the central server. Does this make more sense? A more real world example is something that we have been desiring to do with Autosys. Each release, as the application user changes, the entire schedule must be reloaded with the new user coded in the job definition. If we could use a variable that is evaluated dynamically (as opposed to at the time the schedule is loaded), we could just change the value of this variable, rather than needing to reload the schedule. Let me know if this still doesn't make sense. We probably want to not name it the way I did, because it is a bit confusing. -Brian |