George Joseph wrote:
On Thu, Apr 30, 2015 at 2:01 PM, Joshua Colp <[email protected]
<mailto:[email protected]>> 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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
