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 <j...@apache.org> wrote: > how would this look in code? > > On Aug 8, 2013, at 12:21 , Jason Smith <j...@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 <j...@apache.org> wrote: > > > >> Heya, > >> > >> I’m 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’t have written it, if I hadn’t > >> 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’t 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’s custom one, but that’s hardly a great > >> idea. > >> > >> Other software has the notion of “hooks” (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’d 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 > >> -- > >> > >> > >> > >> > >> > >
