commit | fa1260878f631d17119d3be788a19479dd982364 | [log] [tgz] |
---|---|---|
author | ILYA Khlopotov <iilyak@ca.ibm.com> | Wed Sep 02 08:10:52 2015 -0700 |
committer | ILYA Khlopotov <iilyak@ca.ibm.com> | Wed Sep 02 09:52:56 2015 -0700 |
tree | 602f9d0471932c89e341e55ee3a9a2ab89dd5148 | |
parent | d7eabf6439d0a1f8c7788b4c2a2766206d6a1bbb [diff] |
Introduce 'couch_epi:register_service/1' COUCHDB-2796
couch_epi
is extensible plugin interface (EPI) for couchdb.
Service
's APIProvider
{service_id :: atom(), key :: term()}
- for couch_epi_data_source
service_id :: atom()
- for couch_epi_functions
couch_epi:get_handle(EpiKey)
We monitor the source of config information and have an ability to notify the subscriber. The source is either a file for a couch_epi_data_source
or module for couch_epi_functions
.
If the subscriber wants to receive notifications when the config has been updated it can use:
couch_epi:subscribe(App, Key, Module, Func, ExtraArgs)
The function would be called with following arguments
Fun(App :: app(), Key :: key(), OldData :: notification(), NewData :: notification(), ExtraArgs :: term()
The notification()
is either {data, term()}
or {modules, [module()]}
Any application that wants to register some configuration data for a service using module could add an entry in its supervision tree with something like:
Spec = couch_epi_data:childspec( appname_stats, %% Id appname, %% CurrentApp {epi_key, {couch_stats, definitions}}, appname_stats_config %% Module ).
When service provider wants to learn about all the installed config data for it to use it would then just do something like:
couch_epi:get(Handle, Service, Key)
There are also additional functions to get the same data in various formats
couch_epi:all(Handle)
- returns config data for all services for a given handlecouch_epi:get(Handle, Subscriber)
- returns config data for a given subscribercouch_epi:get_value(Handle, Subscriber, Key)
- returns config data for a given subscriber and keycouch_epi:by_key(Handle, Key)
- returns config data for a given keycouch_epi:by_key(Handle)
- returns config data grouped by keycouch_epi:by_source(Handle)
- returns config data grouped by source (subscriber)couch_epi:keys(Handle)
- returns list of configured keyscouch_epi:subscribers(Handle)
- return list of known subscribersAny application that wants to register some configuration data for a service could add an entry in its supervision tree with something like:
Spec = couch_epi_data_source:childspec( appname_stats, %% Id appname, %% CurrentApp {epi_key, {couch_stats, definitions}}, {priv_file, "couch_stats.cfg"}, [{interval, 5000}] ).
Note we also support {file, FilePath}
instead of {priv_file, File}
The query API is the same as for data
(see data example
)
Any application that wants to register some functions for a service could add an entry in its supervision tree with something like:
Spec = couch_epi_functions:childspec( appname_stats, %% child id appname, %% CurrentApp my_service, my_module %% Module ).
Adding the entry would generate a dispatch methods for any exported function of modules passed.
When app wants to dispatch the call to all service providers it calls
couch_epi:apply(Handle, ServiceId, Function, Args, Opts)
There are multiple ways of doing the apply which is controlled by Opts
Notes:
concurrent
is incompatible with pipe