[asterisk-dev] Contacts, Contact Status and Sorcery

[Joshua Colp]

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