No, I don't think that there are any other reasonable call-points. In fact,
I'm not sure if three is too many, but I'm pretty sure that more would be
a sign that this design isn't right.
-mark
On Fri, Apr 18, 2014 at 5:24 PM, Joseph Smith <[email protected]> wrote:
> I think this sounds reasonable- do you foresee there being any additions
> here? I'm not sure there'd be any more call-points, so it seems like a good
> way to move forward by adding flexibility.
>
> On Apr 18, 2014, at 2:15 PM, Mark Chu-Carroll <[email protected]>
> wrote:
>
> > I'm contemplating making a change to the current configuration plugins.
> I'd
> > like to get a couple of other eyes to glance over it - I'm unsure whether
> > this is sound, or just a reaction to an immediate problem that I
> > encountered working on logging.
> >
> > The way that configuration plugins work right now in the noun/verb
> > framework is super simple. A configuration plugin is an object with an
> > "execute" method. During command dispatch, after the command parser
> > processes the arguments and a command-appropriate context is created,
> the
> > framework iterates over the plugins, and calls the execute method of each
> > one, with the context object and parsed command line parameters.
> >
> > There are two problems that I've encountered working with these in
> practice:
> >
> > 1. Some plugins really want to be run before the command-line arguments
> > are processed, and some want to be run after. For example, for a
> > distributed logging system, we'd like to be able to have the logging
> system
> > optionally enabled before the command is dispatched, so that the
> dispatch
> > process can use logging. But others, for managing things like proxies,
> need
> > to be called after arguments are processed, because they rely on
> arguments.
> > 2. Some plugins need cleanups. For example, in logging again, for best
> > performance, we'd like to use multiprocessing to do asynchronous
> > communication with a logserver. But to do that, we need to do a join
> after
> > the command completes execution. In the current framework, there's no
> way
> > to do that.
> >
> > What I'm thinking about is going more aspect-oriented in the plugins.
> There
> > will be three points during the execution of a command where plugins can
> > get injected:
> >
> > 1. before any argument processing is performed. The only thing that the
> > plugin would be allowed to look at would be the raw, unprocessed
> > command-line parameters. It would return a (potentially) modified copy
> of
> > the parameters, which would be passed to other plugins, and finally to
> the
> > actual noun/verb for the command being executed.
> > 2. after arguments have been processed, but before the noun/verb is
> > executed. This is exactly what the current plugin "execute" method
> does.
> > 3. after the command has completed executing, but before the client
> > exits.
> >
> > The code signatures would be:
> >
> > def beforeDispatch(self, args):
> > """code to execute before dispatching to a noun/verb command.
> > args: a list of the command-line parameters used
> > to invoke aurora.
> > Returns: a possibly modified list of command-line arguments. If
> > this throws an exception, then the execution
> > of the command will be aborted.
> > """
> >
> > def beforeCommand(self, context):
> > """Code to execute after command-line arguments have been
> > processed, but before executing the command. If the
> > code throws a CommandException, then the execution of
> > the command will be aborted.
> > context: the context object that will be used to invoke
> > the command.
> >
> >
> > def cleanupAfterCommand(self, context, returnval):
> > """Code to run after the execution of a noun/verb command has
> > completed, before the command-line application exits.
> > context: the context object that was used to execute the command.
> > returnval: the exit code returned by executing the command.
> > """
> >
> >
> > The order of execution of plugins would remain undefined.
>
>
