Evgeniy Khramtsov wrote:
> 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 :)

Ok. Something needs to be done then. Perhaps it is not correct to run 
table_update when there are no local tables, since that means we are not 
a database master node... have to think about that (and test some probably).

>> 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?

Perhaps. I'm not very fond of the application environment anymore. You 
could very well have the above snippet in your local_xxx.erl file 
though, if we add a hook to retrieve configuration backends. A hook is 
appealing since it allows everyone to solve the problem anyway they like 
(hardcode, os:env variable, your way, ...).

>> 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 :)

I think that if you add your own backend, you can also add your own 
parameter checker... at least I remember that being my intention when I 
wrote the configuration subsystem.

Yxa-devel mailing list

Reply via email to