Fredrik Thulin wrote:

> If you make your AppModule:init/0 return MnesiaTables 'none', 
> sipserver:init_mnesia/1 should not do anything harmful, or does this 
> have some other drawback to you?

sipserver:init_mnesia(none) calls table_update:update(), which fails 
with reason {aborted,{no_exists,{phone,record_name}}}
because that tables doesn't exist of course since i don't need it :)

> I'd propose adding a local.erl function to get configuration backends, 
> and call that from yxa_config:init/1 to get the list of backends 
> instead... write a patch or wait a while until I have the time to fix 
> it (hopefully next week).

Maybe we can simply try to read an environment in yxa_config:init/1? 
Something like

Backends = case application:get_env(AppModule, yxa_config_backends) of
List when is_list(List) ->
   [yxa_config_default | List];
_ ->
   %% Default ?BACKENDS
   [yxa_config_default, yxa_config_erlang]

YXA application writers can easily define their backends in 
corresponding files. Is it acceptable from your point of 

> No, it's not possible because YXA's own configuration parameters are 
> type checked and verified in different ways. Some are mandatory and 
> some are not, for example.
> Either add your variables in yxa_config.hrl, or use the local_ prefix.
> I'd prefer the latter, so that people don't start sending error 
> reports saying "I have this stock YXA application, and it complains 
> about the parameter extra_special_config - please help". If they say 
> "the parameter local_extra_special_config" I'll immediately know that 
> it is not really a stock YXA application =).

OK, I see your point. Actually this is not a big problem for me, since I 
can add "local_" prefixes to unknown parameters in my configuration 
backend and, thus, I will cheat YXA's parameter checker :)

Evgeniy Khramtsov, ProcessOne.

Yxa-devel mailing list

Reply via email to