Sounds good to me. If I understand correctly, this models the API hooks fairly closely (I think they have before/after/on error) and this is before parse / before command / after command, which seems right.
On Fri, Apr 18, 2014 at 2:28 PM, Mark Chu-Carroll <mchucarr...@apache.org>wrote: > 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 <yasumo...@gmail.com> 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 <mchucarr...@apache.org> > > 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. > > > > >
