Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of yasumoto7@gmail.com
 designates 209.85.160.43 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: Re: Client Configuration Plugin Extension Proposal
From: Joseph Smith <yasumoto7@gmail.com>
In-Reply-To: 
 <CAFGkSCmT1vtbau70z-miFbBLwXcyCQy0ah180PTcSzZgEO+SDw@mail.gmail.com>
Date: Mon, 21 Apr 2014 11:56:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <51B6AA22-3501-4FDE-B0D6-C7886913E68F@gmail.com>
References: 
 <CAFGkSCmYXRDC1TW49UzDu0p6bJ8MotCRO71Jw6-o=4-otnHNkA@mail.gmail.com>
 <7970016C-D321-4BCF-99F5-22C3FA832EF8@gmail.com>
 <CAFGkSCmT1vtbau70z-miFbBLwXcyCQy0ah180PTcSzZgEO+SDw@mail.gmail.com>
To: dev@aurora.incubator.apache.org

Yep, that summarizes my thinking as well. #ship

On Apr 18, 2014, at 2:28 PM, Mark Chu-Carroll <mchucarroll@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.
>=20
>    -mark
>=20
>=20
>=20
>=20
> On Fri, Apr 18, 2014 at 5:24 PM, Joseph Smith <yasumoto7@gmail.com> =
wrote:
>=20
>> 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.
>>=20
>> On Apr 18, 2014, at 2:15 PM, Mark Chu-Carroll =
<mchucarroll@apache.org>
>> wrote:
>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> There are two problems that I've encountered working with these in
>> practice:
>>>=20
>>>  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.
>>>=20
>>> 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:
>>>=20
>>>  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.
>>>=20
>>> The code signatures would be:
>>>=20
>>>   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.
>>>     """
>>>=20
>>>   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.
>>>=20
>>>=20
>>>   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.
>>>     """
>>>=20
>>>=20
>>> The order of execution of plugins would remain undefined.
>>=20
>>=20