Splitting hooks out to a plugin/extension

[Shawn Pearce]

Last night I started trying to break the ChangeHookRunner off into a
plugin. I want it out of the core server, I have never been happy with
the idea of that JVM doing fork+exec. Another advantage to breaking
that out into a plugin is any point where that is hooked into the core
will become a natural extension point that any other plugin can also
hook into, and the hook plugin becomes functional example code others
can base their own plugin ideas from.

What do we call this repository?

plugins/hooks
plugins/fork-exec-hooks
plugins/legacy-hooks
plugins/hooks-sop-dislikes

?


After I have the ChangeHookRunner split out, I am also going to eject
stream-events from core into its own plugin. Basically the same
reason, stream-events was a hack a long time ago to support an IRC
chatbot. It never was meant to be a reliable form of delivery. But if
its a plugin, then any point it gets events from the core server is
also available to any other plugin or extension. With the new
ssh-alias feature, admins that rely on it can link it back in as
gerrit stream-events using an alias. With the new plugin data
directory, it might also grow a log file that allows more reliable
event delivery by buffering the last few hours of messages to disk.

[Martin Fick]

Shawn Pearce <s...@google.com> wrote:
>Last night I started trying to break the ChangeHookRunner off into a
>plugin. I want it out of the core server, I have never been happy with
>the idea of that JVM doing fork+exec. Another advantage to breaking
>that out into a plugin is any point where that is hooked into the core
>will become a natural extension point that any other plugin can also
>hook into, and the hook plugin becomes functional example code others
>can base their own plugin ideas from.
>
>What do we call this repository?
>
> plugins/hooks

I think this one makes sense; since we will probably call the new hook points events it should not get confused with the internal points.

>After I have the ChangeHookRunner split out, I am also going to eject
>stream-events from core into its own plugin. Basically the same
>reason, stream-events was a hack a long time ago to support an IRC
>chatbot. It never was meant to be a reliable form of delivery. But if
>its a plugin, then any point it gets events from the core server is
>also available to any other plugin or extension. With the new
>ssh-alias feature, admins that rely on it can link it back in as
>gerrit stream-events using an alias. With the new plugin data
>directory, it might also grow a log file that allows more reliable
>event delivery by buffering the last few hours of messages to disk.

I would call this one event-streams.

-Martin

Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum

[Saša Živkov]

On Mon, May 14, 2012 at 5:27 PM, Martin Fick <mf...@codeaurora.org> wrote:

Shawn Pearce <s...@google.com> wrote:
>Last night I started trying to break the ChangeHookRunner off into a
>plugin. I want it out of the core server, I have never been happy with
>the idea of that JVM doing fork+exec. Another advantage to breaking
>that out into a plugin is any point where that is hooked into the core
>will become a natural extension point that any other plugin can also
>hook into, and the hook plugin becomes functional example code others
>can base their own plugin ideas from.
>
>What do we call this repository?
>
>  plugins/hooks

I think this one makes sense; since we will probably call the new hook points events it should not get confused with the internal points.

 

I also like this name. 

>After I have the ChangeHookRunner split out, I am also going to eject
>stream-events from core into its own plugin. Basically the same
>reason, stream-events was a hack a long time ago to support an IRC
>chatbot. It never was meant to be a reliable form of delivery. But if
>its a plugin, then any point it gets events from the core server is
>also available to any other plugin or extension. With the new
>ssh-alias feature, admins that rely on it can link it back in as
>gerrit stream-events using an alias. With the new plugin data
>directory, it might also grow a log file that allows more reliable
>event delivery by buffering the last few hours of messages to disk.

I would call this one event-streams.

Would the SSH command also get renamed to "event-streams"?

For me the "gerrit stream-events" is easier to read than the "gerrit event-streams".

Saša

 

-Martin

Employee of Qualcomm Innovation Center,Inc. which is a member of Code Aurora Forum

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Shawn Pearce]

On Wed, May 16, 2012 at 5:19 AM, Saša Živkov <ziv...@gmail.com> wrote:
> On Mon, May 14, 2012 at 5:27 PM, Martin Fick <mf...@codeaurora.org> wrote:
>> Shawn Pearce <s...@google.com> wrote:
>> >Last night I started trying to break the ChangeHookRunner off into a
>> >plugin. I want it out of the core server,

...

>> >What do we call this repository?
>> >
>> >  plugins/hooks
>>
>> I think this one makes sense; since we will probably call the new hook
>> points events it should not get confused with the internal points.
>
> I also like this name.

OK, this will be the name.

>> >After I have the ChangeHookRunner split out, I am also going to eject
>> >stream-events from core into its own plugin.

...

>> I would call this one event-streams.
>
> Would the SSH command also get renamed to "event-streams"?

Yes. The top level SSH command always matches the plugin name.

> For me the "gerrit stream-events" is easier to read than the "gerrit
> event-streams".

You can alias this in gerrit.config:

[ssh-alias]
stream-events = event-steams filter-changes

or whatever it is. But yes, it does seem weird to see the "new" name
given how used to the old name we are.