On 10/07/2014 05:57 AM, Joshua Colp wrote:
I'm down with proposal #2 but I have to ask: would this work with
realtime, and how?
(In this response, I refer to the new configuration type as a "compound
type" since I also refer to sorcery wizards, which are a different thing.)
I'm thinking about it, and as long as compound types are restricted to
read-only data, it could be made to work with realtime, but it would
take some sorcery adjustments. The has_* options would have to be
understood at the sorcery level, so that when sorcery is told "retrieve
endpoint foo", sorcery can know to either retrieve the endpoint foo
directly or through a compound type foo that has an endpoint. The
realtime wizard would simply return the entire compound type, and the
sorcery core would extract an endpoint from the returned data.
The other difficult part about realtime is that sorcery.conf relates
sorcery types to entries in extconfig.conf. This means that you would
likely want to have different "type=" for your different compound types
so that each can be stored in different database tables. This takes away
from the ease of just doing "type=wizard" that was proposed. You'd
probably need to have a section in sorcery.conf to tell sorcery the
names of types that are compound types. To illustrate, here's what I'm
thinking:
(sorcery.conf)
[compound_types]
types = phone,trunk
or possibly ensure some level of type-safety by specifying what types
the compound types are composed of:
[compound_types]
phone=endpoint,auth,aor
(pjsip.conf)
[my_phone]
type=phone
has_endpoint=yes
has_aor=yes
...
When sorcery processes "my_phone", it sees type=phone and knows based on
sorcery.conf that this is a compound type and can create individual
objects based on the configuration it comes across.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
