Evgeniy Khramtsov wrote:
> Hello!
> I'm working on SIP gateway to a foreign protocol network and I'm using 
> YXA's SIP stack for that. All works fine, YXA is a realy amazing thing, 


> but I have some questions and proposals.
> 1. When YXA application starts, it passes MnesiaTables to sipserver.erl, 
> which calls init_mnesia(MnesiaTables). However, I don't want to 
> initialize all that YXA's mnesia stuff since I'm using my own mnesia 
> initialization and mnesia tables. So, my proposal is to define 
> "init_mnesia(undefined) -> ok;" in sipserver.erl, and to fix 
> yxa_monitor.erl slightly to make it able to understand 
> {add_mnesia_tables, undefined} message.

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?

> 2. As I can understand, it is not possible to add another config backend 
> without changing YXA's code directly becase ?BACKENDS are hardcoded in 
> yxa_config.erl. This is not really good for me since I want to use my 
> own configuration file :(. Maybe I misread something and it is possible 
> to change config backends in runtime?

I think you are right. This is just because noone else has tried writing 
another configuration backend yet =)

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

> 3. Looks like YXA's config parser fails if it sees unknown variable 
> without "local_" prefix. I wonder if it is possible to avoid such 
> behaviour, because I don't to add "local_" prefixes to my configuration 
> parameters.

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 =).

Yxa-devel mailing list

Reply via email to