[asterisk-dev] Contacts, Contact Status and Sorcery

[Joshua Colp]

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:
>
>
>         Change https://gerrit.asterisk.org/261 sparked some discussion about
>         contacts and contact status so I'd like to continue that here.
>
>         Today, dynamic contacts (incoming registrations) are created on
>         the fly
>         as full sorcery objects and stored in an astdb back-end so they
>         survive
>         a restart.  Permanent contacts however, are created on the fly as
>         sorcery objects when the aor is created but instead of being
>         managed by
>         sorcery, are stored in an aor-specific container. Contact
>         statuses for
>         both types of contacts are created as full sorcery objects and
>         stored in
>         a memory back-end.  They obviously do not survive a restart.
>         This makes
>         navigating the life-cycle of these objects a little convoluted.
>
>         The handling of dynamic contacts is pretty straightforward and I
>         have no
>         issue there.  Permanent contacts are another matter however.
>         Because
>         they aren't managed by sorcery, none of the sorcery life-cycle
>         observers
>         get called and you can't retrieve them by id from sorcery like
>         you can
>         for dynamic contacts.  When you're dealing with contacts in
>         general, you
>         have to understand and account for that.   So, my first
>         suggestion is
>         that we treat the permanent contacts exactly as dynamic ones.   I.E.
>         They become fully-managed objects and get stored in the astdb with a
>         flag or their expiration set such that when asterisk reloads,
>         they get
>         immediately expired.  They'll then be immediately rebuilt as the
>         aors
>         are parsed.  We can then get rid of the aor-specific containers
>         and the
>         processing around them.
>
>
>     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.

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

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

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

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

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