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.219.45 as permitted sender)
MIME-Version: 1.0
Sender: jason.h.smith@gmail.com
In-Reply-To: <001BB5DC-23F7-4BEB-9553-09DCF4F9F5CB@apache.org>
References: <96FBCC7A-F696-4BD8-9B7B-4126F3B5362A@apache.org>
 <CACLy94VaTGpWqrfyBDen5py3tSi1bTVjVyR2dStRmp7q8fy=9g@mail.gmail.com>
 <001BB5DC-23F7-4BEB-9553-09DCF4F9F5CB@apache.org>
From: Jason Smith <jhs@apache.org>
Date: Thu, 8 Aug 2013 17:39:23 +0700
Message-ID: 
 <CACLy94Xtctb+zNJWwzqTnb1sKWJF51f3xKSNYusj+DD-c_9J3A@mail.gmail.com>
Subject: Re: [PLUGINS] Plugin Hooks
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=001a11c20a72b1666104e36d4657

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

Well, I just googled it. Basically there is a couchdb_plugin.erl which
tells Erlang what a behavior looks like. And all that does is define the
functions and arity which a couchdb_plugin would have to export.

Probably there are some better Erlangers on the list who might chime in. It
looks like okay bang-for-buck; only not much bang or much buck.


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

> how would this look in code?
>
> On Aug 8, 2013, at 12:21 , Jason Smith <jhs@apache.org> wrote:
>
> > 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 int=
o
> >> 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 ha=
dn=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=
_log, 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=
 hardly a great
> >> idea.
> >>
> >> Other software has the notion of =E2=80=9Chooks=E2=80=9D (some may cal=
l it 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 th=
e
> >> plugin would have to conform. The plugin registry would just manage th=
e
> >> 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 cod=
e
> >> upgrades e.g.).
> >>
> >>
> >> How do you think we should implement a hooks feature in CouchDB?
> >>
> >>
> >> Thanks!
> >> Jan
> >> --
> >>
> >>
> >>
> >>
> >>
>
>

--001a11c20a72b1666104e36d4657--