George Joseph wrote:
On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <[email protected]
<mailto:[email protected]>> 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. :)
I was referring to dynamic contacts added externally by registration.
<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.
That's an indirect mechanism, and may not order things as expected
unless you force it.
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.
It helps you be able to inject a wizard at the front and have direct
access to manipulate it - without going through the normal wizards
applicable to the object type itself.
<snip>
From who's perspective though?
"I'm implementing qualify/contact status support. I need to store X
information and keep it around only for the lifetime of Asterisk. I need
to know when Y happens. I need to be able to get Z information."
The entire reason I'm asking for such a basic definition of what the
functionality needs is because things keep growing and growing, and we
keep running into things. We need to step back and look at what the
functionality is trying to achieve and how best it can be done over all.
Perhaps without even involving sorcery. Without this basic definition
and (I hesitate to use the words) use cases we may make this into an
even bigger thing when a simple solution would have been the best one
all along.
--
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
