commit | 727cf713265616c842e604224840167fb90d5438 | [log] [tgz] |
---|---|---|
author | Alexander Shorin <kxepal@apache.org> | Sun Oct 18 01:19:53 2015 +0300 |
committer | Alexander Shorin <kxepal@apache.org> | Tue Oct 27 22:08:45 2015 +0300 |
tree | 88493237fb2399449ad98f11b08ea23a1efc3754 | |
parent | c359a6900c193211a77004df9a31c2ad4bcddf9d [diff] |
Integrate with Travis CI
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 modules involved in configuration of the service/provider so we get notified when there is a code upgrade. We use this notification in order to:
Call to notify/3 would be called for both providers and data_providers.
Any application that wants to register some configuration data for a service using module could add an entry in its implementation of couch_epi_plugin behaviour:
data_providers() -> [ {{couch_stats, descriptions}, {priv_file, "stats_descriptions.cfg"}, [{interval, 5000}]} {{couch_stats, descriptions}, {file, "/tmp/extra_stats.cfg"}, [{interval, 5000}]}, {{couch_stats, descriptions}, {module, my_stats}} ].
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)
The service provider also have to mention the data keys it is using in its implementation of couch_epi_plugin behaviour
data_subscriptions() -> [{couch_stats, descriptions}].
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 implementation functions for a service could add following into it's implementation of couch_epi_plugin behaviour:
providers() -> [{my_service, module_which_implements_the_functions}].
Adding the entry would generate a dispatch methods for any exported function of modules passed.
Services have to be defined in one of the implementations of couch_epi_plugin behaviour as:
services() -> [{my_service, module_to_monitor_for_codechange}].
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
The module implementing behaviour need to export following functions: