Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jason.h.smith@gmail.com
 designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
Sender: jason.h.smith@gmail.com
In-Reply-To: <96FBCC7A-F696-4BD8-9B7B-4126F3B5362A@apache.org>
References: <96FBCC7A-F696-4BD8-9B7B-4126F3B5362A@apache.org>
From: Jason Smith <jhs@apache.org>
Date: Thu, 8 Aug 2013 17:21:52 +0700
Message-ID: 
 <CACLy94VaTGpWqrfyBDen5py3tSi1bTVjVyR2dStRmp7q8fy=9g@mail.gmail.com>
Subject: Re: [PLUGINS] Plugin Hooks
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2f80002347504e36d08c2

--001a11c2f80002347504e36d08c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Perhaps a custom behaviour to help catch API problems at compile time?

    -behaviour(couchdb_plugin).


On Thu, Aug 8, 2013 at 3:47 PM, Jan Lehnardt <jan@apache.org> wrote:

> Heya,
>
> I=E2=80=99m toying with the idea of moving some of my experimental into
> bona-fide plugins. One of them is my log_to_db branch that on top of
> writing log messages to a text file also writes a document to a log
> database.
>
> Conceptually, this is the perfect use of a plugin: the feature is not
> useful in the general case, because *any* activity creates write load
> on a single database, but for certain low-volume installations, this
> might be a useful feature (I wouldn=E2=80=99t have written it, if I hadn=
=E2=80=99t
> needed it at some point) so allowing users to enable it as a plugin
> would be nice.
>
> But regardless of whether my plugin is useful, it illustrates an
> interesting point:
>
> A log_to_db plugin would need to register for logging events or, if it
> doesn=E2=80=99t want to duplicate all the logging-level logic in couch_lo=
g, it
> would need some way of injecting a function call into
> `couch_log:log().`. We could of course try and find a way where a
> plugin would be able to provide an API compatible version of a CouchDB
> module and swap it out for it=E2=80=99s custom one, but that=E2=80=99s ha=
rdly a great
> idea.
>
> Other software has the notion of =E2=80=9Chooks=E2=80=9D (some may call i=
t something
> else) where at well defined points in the main code base, external
> functions get called with certain parameters. To make things dynamic,
> there might be a way for plugins to register to be called by those
> hooks and the main code then asks the registry whether there are any
> plugin functions to call.
>
> In the log_to_db example, we=E2=80=99d have something like this:
>
> couch_log_to_db.erl:
>
>     init() ->
>         couch_hooks:register(couch_log_hook, log_hook_fun/1),
>         ok.
>
>     log_hook_fun(Log) ->
>         % do the log_to_db magic
>         ok.
>
>
> couch_hooks.erl:
>
>     register(Hook, Fun) ->
>         % store the Fun with the Hook somewhere
>         ok.
>
>     call(Hook, Args) ->
>          % retrieve Fun for Hook from somewhere
>         Fun(Args).
>
> couch_log.erl:
>
> % in log()
>
>     ...
>     couch_hooks:call(couch_log_hook, Args),
>     ...
>
> The main code would define what the hook name and arguments are and the
> plugin would have to conform. The plugin registry would just manage the
> registration and calling of functions for a hook, but nothing more.
>
> * * *
>
> This is just my first stab at this not thinking about it too much and I
> likely miss some subtleties in Erlang that make this not work (hot code
> upgrades e.g.).
>
>
> How do you think we should implement a hooks feature in CouchDB?
>
>
> Thanks!
> Jan
> --
>
>
>
>
>

--001a11c2f80002347504e36d08c2--