[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp <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>> 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/d125f679/attachment.html>