bkml ha scritto:
 > I have therefore been looking at a different angle. I thought "how 
about pretending that #1, #2 and #3 are three totally different  issues, 
then solving each one isolated from the other two?". Some 
experimentation led to the following ...

[Cut]

Imho it's still the wrong angle.

You can't do assumptions that won't be true in the future (and probably 
even now).
Chan_sofia will need more parameters that will give more flexibility, 
so, mypoint of view is:

1) Dial() requires 3 kinds of arguments:

  a) it's own parameters, like timeout, and all that stuff

  b) the TECH of the channel (SIP/ZAP/MISDN) which is NOT needed by 
Dial() itself but is needed by the core (to call the appropriate channel 
driver)

  c) the channel specific arguments like sip uri, sip peer, zap 
extensio, zap group etcc.


2) data for a) can be schematized, data for b) and c) cannot be really 
schematized in an appropriate way. After all it's not something that 
Dial() should take care of.


3) b) and c) shound't even be a problem of Dial().
it's a whole thing that the CORE must take care of.

Dial as an application cannot and must not take care of those data.


4) if you want to be more schematic, then use something like

Dial ("tT", "TECH1/parameters","TECH2/more_parameters",[...more channels])

from the 2nd argument to the nth one, it's the core that should take 
care of them. Not dial.


MAx







_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev

Reply via email to