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.
<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:
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.
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"
That sort of thing.
--
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
