[asterisk-dev] Contacts, Contact Status and Sorcery
Joshua Colp
jcolp at digium.com
Thu Apr 30 18:23:55 CDT 2015
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.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
More information about the asterisk-dev
mailing list