Before we publish a "verison 1.0" I would like to propose a change in the way we name the published work names for injector, ejector and the default controller.
I would like to make a statement that the user of gearsloth should have a rudimentary understanding of the infrastructure they are setting up. To promote this and also to lean on this assumption, I propose that we name the published work according to the component names. This would mean that the function that the "injector" component published would be "inject" and the function that the "ejector" component published would be "eject". The default controller function could in the same logic be called "control".
Also prefixing the functions would be a good idea to prevent clashes with other systems in the same gearman cluster. Thus I propose that the new names for the published functions would be:
gearsloth_inject
gearsloth_eject
gearsloth_control
And as proposed in #27 I would love the "gearsloth" prefix to be configured so that the tasks could be:
my_namespace_inject
my_namespace_eject
my_namespace_control
This would allow multiple different gearsloth systems to be run within single gearmand cluster. This would be beneficial for systems which have different types of tasks, where others need higher promises of persistence and others higher promises of availability and performance. The programmer could the choose between using "secure_gearsloth_inject" and "fast_gearsloth_inject" depending on the task.
Before we publish a "verison 1.0" I would like to propose a change in the way we name the published work names for injector, ejector and the default controller.
I would like to make a statement that the user of gearsloth should have a rudimentary understanding of the infrastructure they are setting up. To promote this and also to lean on this assumption, I propose that we name the published work according to the component names. This would mean that the function that the "injector" component published would be "inject" and the function that the "ejector" component published would be "eject". The default controller function could in the same logic be called "control".
Also prefixing the functions would be a good idea to prevent clashes with other systems in the same gearman cluster. Thus I propose that the new names for the published functions would be:
And as proposed in #27 I would love the "gearsloth" prefix to be configured so that the tasks could be:
This would allow multiple different gearsloth systems to be run within single gearmand cluster. This would be beneficial for systems which have different types of tasks, where others need higher promises of persistence and others higher promises of availability and performance. The programmer could the choose between using "secure_gearsloth_inject" and "fast_gearsloth_inject" depending on the task.