[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

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



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


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


>
>>
>>
>>
>>              What if they could be?
>>              What if you could add a wizard that's marked as caching (so
>>         it's
>>              only queried) but still have a handle to it to
>>         create/update/destroy?
>>
>>
>>         You just described res_pjsip_config_wizard exactly.
>>
>>
>>     Yes, except without having a direct handle and more control over
>>     things you had to do it in an indirect manner.
>>
>>
>>
>>              Wrap that up in a higher level API like you want above and
>> you
>>              extend sorcery in a way that's useful in multiple ways.
>>
>>
>>         Put the whole mutability thing aside for a minute.  I guess what
>> I'm
>>         suggesting that the default sorcery behavior could be an automatic
>>         read/write cache in front of every sorcery wizard.  You can then
>>         control
>>         whether how writes are handled (if at all) by options you give
>>         when you
>>         register the object type, and options you give on CRUD calls.
>>
>>
>>     I'm not a fan of automatic anything or complicating the sorcery core
>>     any further. Higher level stuff built on top which has to be
>>     explicitly done by users, yes.
>>
>>
>> I think that's true in some cases but in others, you don't want "users"
>> doing it 50 different ways where something carefully crafted at a lower
>> level will do the trick.
>>
>
> No, I don't, but I also don't want the lower level sorcery core to become
> even more complex and have additional burden. Thin, simple (as much as
> possible), to the point. If higher level APIs exist which build on it to
> provide the functionality then I'm all for it.
>
>
>>
>>
>>         For my contact scenario, I'd say writable cache and a writable
>>         back end
>>         (astdb by default).  When writing a new dynamic contact or
>>         updating the
>>         expiration, I'd say write-through.  When updating status, I'd say
>>         cache-only.   For permanent contacts, it would always be
>> cache-only.
>>
>>
>>     So - stepping back and implementation details aside. What do we
>>     need? In an ideal world how would the implementation work?
>>
>>
>> Fair question.
>>
>> I want to CUD objects and decide whether the results of the operation
>> should be temporary or persistent at the time I perform the operation.
>> I don't want to have to create my own wizard some other specific
>> implementation each time I need this capability.
>>
>> I want to dynamically create an object and not have to worry that the
>> underlying wizard was res_sorcery_config and therefore doesn't support
>> create.
>>
>> I want to update an object and call ast_sorcery_update without having to
>> clone it.   It's my job to assess locking requirements.  It's sorcery's
>> job to determine whether the object needs to be cloned.  A
>> "get_for_update" might help there.  It could either lock it before
>> giving it to you  or clone it before giving it to you.
>>
>
> This is even lower level then I was thinking of. Within the scope of
> contacts and contact status - what would be the best way for them to work?
>
> "When a contact status changes I need to be able to store this information"
>

>From who's perspective though?

When any contact is added, updated or deleted, I want the same observer to
be called.  I don't want to have to code differently for permanent contacts
vs dynamic contacts.

I want to create a temporary contact that sticks around until I delete it
or Asterisk restarts.

I want to update a contact's status/rtt and indicate that the change should
be discarded when Asterisk restarts.

I want to update expiration and indicate that the change should be
permanent.

I don't want to care which wizards support CUD and which don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/0804b84e/attachment-0001.html>