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]
end.
YXA application writers can easily define their backends in
corresponding appmodule.app files. Is it acceptable from your point of
view?
> 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 :)
--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:[EMAIL PROTECTED]
_______________________________________________
Yxa-devel mailing list
[email protected]
https://lists.su.se/mailman/listinfo/yxa-devel
