Use a proplist as the format used to define services in the configuration

[jcomellas]

Currently, to define/configure a service in CloudI we have to provide a tuple with 13 (for internal services) or 17 (for external services) fields. This makes the service definition difficult to understand when looking at the code.

I would suggest allowing the use of a proplist when defining the services to improve readability. For the key names, we could use the same field names that are currently used in the internal and external records.

An internal service could be defined by a proplist with the following format:

[{prefix,           cloudi:service_name_pattern()},
 {module,           atom() | file:filename()},
 {args,             list()},
 {dest_refresh,     cloudi_service_api:dest_refresh()},
 {timeout_init,     cloudi_service_api:timeout_milliseconds()},
 {timeout_async,    cloudi_service_api:timeout_milliseconds()},
 {timeout_sync,     cloudi_service_api:timeout_milliseconds()},
 {dest_list_deny,   cloudi_service_api:dest_list()},
 {dest_list_allow,  cloudi_service_api:dest_list()},
 {count_process,    pos_integer()},
 {max_r,            non_neg_integer()},
 {max_t,            cloudi_service_api:seconds()},
 {options,          cloudi_service_api:service_options_internal()}]

Whereas an external service could be defined in this way:

[{prefix,           cloudi:service_name_pattern()},
 {file_path,        file:filename()},
 {args,             string()},
 {env,              list({string(), string()})},
 {dest_refresh,     cloudi_service_api:dest_refresh()},
 {protocol,         'default' | 'local' | 'tcp' | 'udp'},
 {buffer_size,      'default' | pos_integer()},
 {timeout_init,     cloudi_service_api:timeout_milliseconds()},
 {timeout_async,    cloudi_service_api:timeout_milliseconds()},
 {timeout_sync,     cloudi_service_api:timeout_milliseconds()},
 {dest_list_deny,   cloudi_service_api:dest_list()},
 {dest_list_allow,  cloudi_service_api:dest_list()},
 {count_process,    pos_integer()},
 {count_thread,     pos_integer()},
 {max_r,            non_neg_integer()},
 {max_t,            cloudi_service_api:seconds()},
 {options,          cloudi_service_api:service_options_external()}]

The added benefit of using a proplist is that we could have sane defaults for most of the non-essential fields, thus reducing the number of required fields.

[okeuday]

The default configuration file (in the CloudI repo) has example usage of the proplist configuration method (the keys are based on the record field names). The record configuration format is still used for everything underneath, including the data returned from cloudi_service_api:services/1

[okeuday]

(i.e., the proplist format is the same as what you suggested)