[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

On Thu, Apr 30, 2015 at 4:45 PM, George Joseph <george.joseph at fairview5.com>
wrote:

>
>
> 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.
>
>
> Oh yeah.  I don't want a user to have to screw around with sorcery.conf to
get basic behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/862bfcce/attachment.html>