Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.214.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAHdjipK6z+gQBkjUvv8OaCqjMQx5ja0OG1ULpKX=qbjSV1dTGQ@mail.gmail.com>
References: <96FBCC7A-F696-4BD8-9B7B-4126F3B5362A@apache.org>
 <CAHdjipK6z+gQBkjUvv8OaCqjMQx5ja0OG1ULpKX=qbjSV1dTGQ@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Thu, 8 Aug 2013 09:13:17 -0500
Message-ID: 
 <CAJ_m3YAtoTWFsvF34A2ReR5caGS6No_PhLfzKxXG4bHs7Hsp1g@mail.gmail.com>
Subject: Re: [PLUGINS] Plugin Hooks
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Skimming over it I'm not convinced its any better than just writing a
standard Erlang application. There's a bit more boilerplate but I
don't see the move to a non-standard Erlang project structure as a net
win.

On Thu, Aug 8, 2013 at 9:08 AM, Alexander Shorin <kxepal@gmail.com> wrote:
> Hi Jan!
>
> Have you looked at eplugin? Can he be useful?
>
> https://github.com/Licenser/eplugin
> --
> ,,,^..^,,,
>
>
> On Thu, Aug 8, 2013 at 12:47 PM, Jan Lehnardt <jan@apache.org> wrote:
>> 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 grea=
t
>> 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
>> --
>>
>>
>>
>>