[asterisk-dev] Contacts, Contact Status and Sorcery

[Joshua Colp]

George Joseph wrote:
>
>
> On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <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.

-- 
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