On Tue, Oct 7, 2014 at 8:37 AM, Mark Michelson <mmichel...@digium.com> wrote:
> 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? >> >> > If you're going through the trouble of setting up realtime I wonder if you would get any benefit from the config wizard approach. Having said that, see below. > (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. > > Although the ast_sorcery_* API doesn't expose it, an object can be mapped to multiple wizards, right? What if the compound object was stored in, and retrieved from, one of the concrete wizards but the objects it creates are created in a memory wizard that's added to the object_type's wizards container. Unfortunately, this doesn't address the real time aspect of realtime. If you make a change to the backing compound object data store it's not automatically propagated to the created objects. This brings be back to my question above... If you're using realtime are you likely to even need the wizard approach. I'm still thinking.
-- _____________________________________________________________________ -- 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
