[asterisk-dev] Contacts, Contact Status and Sorcery

[George Joseph]

On Thu, Apr 30, 2015 at 3:03 PM, Joshua Colp <jcolp at digium.com> wrote:

> George Joseph wrote:
>
>>
>>
>> On Thu, Apr 30, 2015 at 2:01 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? :)


> <snip>
>
>
>>     A contact is updated when the registration is refreshed, you have to
>>     persist that out to disk or if a restart occurs it'll be expired.
>>
>>
>> Yes, so for dynamic contacts, the expiration would be written with the
>> normal update and for status and rtt changes, with update_temp.
>>
>
> I experimented with doing this when sorcery was originally, partitioning
> an object to exist in multiple places. It was not easy to get it right.
>

I've done this a number of times for large OLTP systems where there's data
you want in a scratchpad that may nor may not ever be persisted.   If it's
implemented at the correct layer, it becomes invisible.


>
>
>>
>>         For permanent contacts, we do the same except we call
>>         ast_sorcery_create_temp and ast_sorcery_delete_temp so they
>>         never get
>>         persisted to astdb.
>>
>>
>>     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.


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


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

I think that sums it up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150430/8aa893f5/attachment.html>