[asterisk-dev] Contacts, Contact Status and Sorcery
George Joseph
george.joseph at fairview5.com
Thu Apr 30 18:32:58 CDT 2015
On Thu, Apr 30, 2015 at 5:23 PM, Joshua Colp <jcolp at digium.com> wrote:
> George Joseph wrote:
>
>> On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp <jcolp at digium.com
>> <mailto:jcolp at digium.com>> wrote:
>>
>> George Joseph wrote:
>>
>>
>>
>> On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <jcolp at digium.com
>> <mailto:jcolp at digium.com>
>> <mailto:jcolp at digium.com <mailto:jcolp at digium.com>>> wrote:
>>
>> George Joseph wrote:
>>
>> <snip>
>>
>>
>>
>> What if contacts are stored in an external
>> database? Your
>> proposal
>> would also have them going there as well.
>> This
>> would require an
>> explanation for deployers to know what is
>> going on
>> exactly
>> and what
>> they are. As well this means there would
>> be a
>> period of
>> time where
>> the permanent contacts would not be
>> present if other
>> instances are
>> sharing the same database and one restarts.
>>
>>
>> They can't be today can they? The dynamic
>> ones are
>> explicitly
>> mapped to
>> astdb and the permanent ones are explicitly
>> placed in
>> the aor based
>> container. Can you even use sorcery.conf to
>> map contacts
>> somewhere else
>> given that they're just strings in an aor?
>>
>>
>> You sure can.
>>
>>
>> Who would even know they can do that besides you? :)
>>
>>
>> I believe there's a wiki page which details using PJSIP with
>> realtime, and there's also the table in alembic.
>>
>>
>> In general there is. There aren't any specific instructions for
>> contacts though. Permanent contacts specifically. The ERD on
>> the wiki
>> shows contact but pjsip.conf.sample only mentions contacts in the
>> context of aors. There's no object mentioned. If we took a
>> poll, how
>> many people would respond that they know they could define
>> permanent
>> contacts in realtime as separate objects. :)
>>
>>
>> I was referring to dynamic contacts added externally by registration.
>>
>>
>> <snip>
>>
>> So. This is what I was originally trying to
>> express when
>> you did the
>> wizard work, you've just gone about it in a
>> different manner. I
>> think this is a rather specialized
>> addition that
>> could be
>> done in a
>> better way.
>>
>> Right now sorcery wizards can't be
>> programmatically added.
>> They just
>> can't. You have to do it from the
>> sorcery.conf
>> configuration file.
>>
>>
>> Not true. ast_sorcery_apply_wizard_mapping
>> allows yo
>> to add a
>> wizard to
>> any object type at run time. That's what the
>> config_wizard
>> does. When
>> the object type registers, it adds a memory
>> wizard to
>> the object
>> type's
>> wizard list. The config wizard then
>> manipulates the
>> memory wizard.
>>
>>
>> It adds a wizard but does not return a handle to
>> it. It
>> also doesn't
>> allow you to specify where to place it. It's
>> always at the end.
>>
>>
>> You don't need a handle, you have the wizard itself.
>> Correct on
>> the order.
>>
>>
>> How? What I'm talking about is something like:
>>
>>
>> You can get the wizard as a result of the wizard_mapped observer.
>>
>>
>> That's an indirect mechanism, and may not order things as expected
>> unless you force it.
>>
>>
>>
>> int res;
>> struct ast_sorcery_wizard *wizard;
>> void *data;
>> res = ast_sorcery_apply_explicit_wizard(sorcery, "endpoint",
>> "memory", "", &wizard, &data);
>>
>> That function would explicit at a wizard to the front, and
>> return
>> the specific wizard interface and instance. Instant access to
>> manipulate that specific instance with the CRUD interface
>> and a
>> guarantee of its position.
>>
>>
>> Agreed and that's easy enough. I'm not sure it helps any though.
>>
>>
>> It helps you be able to inject a wizard at the front and have direct
>> access to manipulate it - without going through the normal wizards
>> applicable to the object type itself.
>>
>> <snip>
>>
>>
>>
>> From who's perspective though?
>>
>>
>> "I'm implementing qualify/contact status support. I need to store X
>> information and keep it around only for the lifetime of Asterisk. I
>> need to know when Y happens. I need to be able to get Z information."
>>
>> The entire reason I'm asking for such a basic definition of what the
>> functionality needs is because things keep growing and growing, and
>> we keep running into things. We need to step back and look at what
>> the functionality is trying to achieve and how best it can be done
>> over all. Perhaps without even involving sorcery. Without this basic
>> definition and (I hesitate to use the words) use cases we may make
>> this into an even bigger thing when a simple solution would have
>> been the best one all along.
>>
>>
>> True but we also risk a point solution that's not good for anything else.
>>
>> How about this, let me start with a patch that adds the wizard mods.
>> Maybe "ast_sorcery_insert_wizard" that looks like your prototype with a
>> parameter for order. WIZARD_FIRST, WIZARD_LAST or something.
>>
>
> I think that would be a fine addition.
>
>
>> Then let me propose how I'd use it to create a wizard specifically for
>> contacts. Then we can decide if it could be generalized for other use
>> or left specifically for contacts.
>>
>
> Sure, but without an actual idea of what problem is trying to be solved or
> how things will be improved - it's hard to say if that's the right solution.
>
>
Understood, but I'll outline that with the proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/a8a269e4/attachment-0001.html>
More information about the asterisk-dev
mailing list