Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (athena.apache.org: local policy)
From: Jan Lehnardt <jan@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_E66675AE-D96F-47D8-826D-E7DC5ACC2503";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Subject: [PLUGINS] Plugin Hooks
Message-Id: <96FBCC7A-F696-4BD8-9B7B-4126F3B5362A@apache.org>
Date: Thu, 8 Aug 2013 10:47:55 +0200
To: "dev@couchdb.apache.org Developers" <dev@couchdb.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))

--Apple-Mail=_E66675AE-D96F-47D8-826D-E7DC5ACC2503
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Heya,

I=92m 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=92t have written it, if I hadn=92t
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=92t 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=92s custom one, but that=92s hardly a =
great
idea.

Other software has the notion of =93hooks=94 (some may call 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=92d 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
--=20


--Apple-Mail=_E66675AE-D96F-47D8-826D-E7DC5ACC2503
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEUEARECAAYFAlIDWzwACgkQ7KW8t7uWVrCKzgCY3E0D5PqMOZO6at6s4y2aDKsw
QQCfUsvm0zMZxBJ031J4+L+z41P2BkM=
=mVlV
-----END PGP SIGNATURE-----

--Apple-Mail=_E66675AE-D96F-47D8-826D-E7DC5ACC2503--